Date: prev next · Thread: first prev next last
2013 Archives by date, by thread · List index


On Wed, 2013-12-11 at 17:19 +0100, Sophie wrote:
Hi all,

This mail is posted to the dev list and the l10n list, please follow up
on the l10n list.

I would like to open a discussion on the l10n workflow, the quality of
the en_US version and the Help files. All is linked and I would like to
discuss how we can improve the process here. I'm sure that having a
better understanding between the l10n process and the dev process should
help us to improve things :) So here is a proposal, it's a bit long,
sorry for that.

*Before updating Pootle:
- it's important for l10n team to know the approx load of work that will
be needed to achieve the whole work. Time between beta1 and rc1 is short
and that will help to better organize this time between translation and
proof reading.
- depending also on the type of changes, we could use different tools to
optimize the work.

*When the l10n start:
- we need a continuous communication and a planing of the updates made
in Pootle, those translating off line are always frightened to lose
something in the run.
- it's exhausting when you think you are over and to see a new bunch of
words coming. Knowing it in advance help to manage the time too

*After RC1 and l10n integration
- we need to know when integration is made after our fixes, there is
currently no communication on this

==> for these three items, I have asked today to Andras and Christian
how we can put that in place and where I can help them to do so, knowing
also that Christian is managing this part almost alone now.

*About the en_US overall quality
- the process to rely on the l10n team to fix the en_US version is ok,
even if it gives us extra work to understand what is meant before we
realized it's a mistake. So it's also error prone for all the translations.
- but that doesn't solve the several typos that already exist and that
are overlooked by the l10n team (e.g in the Character > Font Effect
dialog, there is Overline _c_olor and Underline _C_olor and this is the
same for several dialogs)
- that doesn't solve also the lack of universal vocabulary used in
several dialogs (e.g Tab/Pane/Panel/Deck to name the same object or
Graphic/Picture/Image). I've nothing to propose here but to define a
glossary where developers could pick the good word but I'm not sure it
will be used


* About the help files
- I always wonder why there is a Help button on a new dialog when no
help file is appended ;)

One thing that we could with the new .ui file format is to confirm if
each dialog actually has a help entry for it. There is an easy hack at
https://bugs.freedesktop.org/show_bug.cgi?id=67350 to extract out the
new-format helpids from the help and determine if they actually exist.
That would weed out typos where the help gets detached from the thing it
documents.

Similarly someone could script if each new-format dialog has a help
entry and make a list of stuff that is missing help and turn those into
a list of tasks to document those things.

Another thing that could be automated is to generate a skeleton help
page from a new-format dialog. i.e. generate the help ids bookmarks for
the interactive widgets, buttons, checkboxes, etc. and have fill-me-in
headings and bodytext.

C.


Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.