Re: [libreoffice-l10n] Re: l10n process, en_US version, Help files

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