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


Hi Christian,
Le 12/12/2013 13:56, Christian Lohmaier a écrit :
Hi Sophie, *,

On Wed, Dec 11, 2013 at 5:19 PM, Sophie <gautier.sophie@gmail.com> wrote:
[...]
*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.

Don't think this applies to a new minor version, as a new project is
created, the old one just renamed, so you immediately see in the new
project how much work is left. And only with that info you can decide
what meaningful way there is to minimize actual translation work.

That doesn't apply to minor version, but for major version where we have
only few new strings and the rest is xml manipulations. I've discovered
that translation tools handle this very differently so knowing before
the new strings versus what we have already in our TM or commented in
the po files, etc... imho would help. But this may be simply not
possible for you, I'm not enough technical to know, which is why I ask :)

*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

Yes, of course, and let me reiterate: I did not update any templates
in December. Whoever else did update them did so without prior notice.
I fully agree that before templates are updated l10n teams should be warned.
(but then again, I don't consider adding a new project as updating
templates in this regard - if the new data is wrong, just copy from
the old project, no loss, no additional work, no mixup with offline
translations)

Yes, and again, this is discussion is by no mean to point somebody
mistake, but only to enhance our process and our communication.

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

For every build it is the same: Translations are extracted from pootle
on Tuesday and committed before tagging. Deadline for each tag is
Monday. So if you add your changes on Monday, all is fine, your
translations will be included. If you wait till Tuesday, your changes
might be missed.

The release schedule overview is available here:
https://wiki.documentfoundation.org/ReleasePlan
or more detailed for the next relevant releases:
https://wiki.documentfoundation.org/ReleasePlan/4.2#4.2.0_release
https://wiki.documentfoundation.org/ReleasePlan/4.1#4.1.5_release

There you see the dates for the relevant releases, and also in the
case of a new feature release the UI and string freeze dates.

If you look at the 4.2.0 schedule, you see that English string freeze
is next week (Monday, Dec 16) - so that is the week I did plan for
updating the templates in pootle.
I will grab the translations on Tuesday as for every build, (that way
there is a copy of the transations in the sourcecode, in case
something goes wrong with updating the templates), and after that
would add the new templates to pootle for l10nprojects to update.

Then l10n projects have a month to adapt to those late changes.

Ok, I'll add this to our l10n pages so new comers know how it works.

==> 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.

Yes, 4.2.0 was the first time I did update the projects in pootle, and
I personally think it was not a huge desaster.

me too, be sure and thanks a lot for your work :)
 There were two
stumbling stones:
1) update_against_templates aborting because of added/renamed files
2) lots of changes in help that only affect metadata (the xml-tag
attributes), not the actual translations

first was causing only a fraction of the changes to show up, leading
to the impression that almost nothing changes, and after that was
fixed, the second one caused a huge string count to be displayed,
probably making some translators think that suddenly their
translations were deleted or something, since after 1) they thought
they were almost finished.
2) was fixed with a script shortly afterwards, leaving only the real
changes to process.

ok, thank you for the details


Now what happened in December is a completely different story, esp.
that kk project did end up having Greek translation is still a
mystery, but not related to any updates.

*About the en_US overall quality
- [...]
- 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,

Those that have been reported on the list have been fixed by Andras or
me in the code - and people are very welcome to upload a patch to
gerrit themselves. (
https://wiki.documentfoundation.org/Development/gerrit )

My concern is for what is not reported by us (and hence, not reported at
all), I know that Andras and you are fixing very quickly what we
reported here or on the QA list.

- 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

Graphic/Picture/Image is for example one of the changes that have
already been somewhat unified for 4.2 - but yes, a
terminology/glossary doesn't really exist.

And I'm not sure it will be used anyway, I don't have the solution
currently :)

* About the help files
[...]
May be, but I don't know how heavy it would be for developers, the
solution would be to open an issue with a special tag like NF for each
new feature, with three lines about what the feature is supposed to
do.

Yes, this is a flaw by the committer/reviewers, who let the new
functionality pass into the code without making sure documentation is
created as well.

I guess it would help a lot if there is a group willing to write the
documentation when devs just say something like "I changed/added
functionality xy, please adapt the documentation to it"
Having devs write the documentation themselves doesn't necessarily
make it helpful :-)

lol, yes. I propose an issue because it's a tool used by developers and
it's easy to query for other teams, much more easy than gerrit and the
issue can be linked to the patch (or the other way round).

Cheers
Sophie

-- 
Sophie Gautier <sophie.gautier@documentfoundation.org>
Tel:+33683901545
Membership & Certification Committee Member - Co-founder
The Document Foundation

-- 
To unsubscribe e-mail to: l10n+unsubscribe@global.libreoffice.org
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/l10n/
All messages sent to this list will be publicly archived and cannot be deleted

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.