[libreoffice-l10n] Re: Workflow between dev, UX and l10n teams

Tom Davies tomcecf at gmail.com
Mon Jan 26 03:15:56 PST 2015


Hi :)
Yes that suggestion was put forwards in the previous thread and i
still think it is an excellent idea - or at least has a lot of merit.
I seem to remember there were excellent reasons why it might be
unworkable but i'm not sure if they really are total blockers.
Regards from
Tom :)


On 26 January 2015 at 10:52, Jesper Hertel <jesper.hertel at gmail.com> wrote:
> Hi Sophie and everybody else,
>
> Well I didn't answer as I didn't feel like finding out what the "projects@
> list" was and joining that list to be able to join the discussion there.
>
> I will answer here.
>
> I did not read the whole previous discussion but did anyone suggest to add
> a new en-us translation language in Pootle and let that be the place where
> all non-semantic changes to the en-us strings happen? That way the current
> strings in the source code will turn into mere translation keys written in
> en-us. The final en-us polishing will then happen in the translation files
> just like any other language and will of course not affect any of the other
> languages.
>
> Any semantic change should of course still happen in the "keys", i.e. the
> source code, but non-semantic changes should be prohibited there and
> instead made in the en-us translation in Pootle.
>
> This might be something obvious that you already talked a lot about, but I
> just want to make sure this option isn't overlooked.
>
> Jesper
> Den 26/01/2015 09.34 skrev "Sophie" <gautier.sophie at gmail.com>:
>
>> Hi,
>>
>> Resending as there was no answer to the proposals :)
>> Cheers
>> Sophie
>> Le 19/01/2015 11:03, Sophie a écrit :
>> > Hi all,
>> >
>> > [Please follow-up the discussion on projects@ list to keep the history
>> > of the thread there and ease the discussion, thanks :-)]
>> >
>> > I would like to open a discussion about the way developers team, UX team
>> > and l10n team should interact and work together.
>> >
>> > There has been a heavy discussion [see this thread 1] during this round
>> > of translation. The l10n team was a bit frustrated that there were again
>> > so many changes in the en_US version that does not concern the l10n
>> > versions (like adding colon at the end or capitals in the middle of the
>> > strings).
>> >
>> > Each time, it seems part of this could be automated or a reflection
>> > on how to avoid messing the l10n work should have been introduced before
>> > those changes are committed. For example, if I decide to change FR
>> > localization to have sentence capitalization in the menu entries, none
>> > of the 100 other localizations won't and shouldn't be affected. It
>> > should be the same for en_US version or if really impossible, try to
>> > find a solution that lower the impact on all localizations.
>> >
>> > None of the l10n teams is against changing or correcting the UI of the
>> > en_US version and none is against the natural evolution of the suite.
>> > What is not bearable is when you have 100 000 changes in en_US and only
>> > a 1/3 concerns all the other languages and it is repeated over the
>> > branches.
>> >
>> > We are trying to change our workflow to work on master instead of
>> > branches. That will allow us to review the strings earlier (to leverage
>> > heavy unneeded changes if possible) and have more time to localize. But
>> > that will work only if each taking part of the changes take care of the
>> > others.
>> >
>> > To conclude, what l10n team would like to see is:
>> > - a review process of the strings before they are committed and make
>> > sure they respect the en_US standards (capitals, grammar, punctuation,
>> > typography). Maybe adding the Gnome HIG book to our pages [like 2] if
>> > not already.
>> >
>> > - if there is a way to script changes, script them otherwise wait until
>> > there is a script available to commit them
>> >
>> > - any time there are heavy changes that pop up in someone's mind (like
>> > changing ... for …) discuss it with the l10n team before committing
>> > those changes.
>> >
>> > I know it may lower the enthusiasm of some contributors, but it will
>> > regain the one of our l10n teams for sure :)
>> >
>> >
>> > [1]
>> >
>> http://nabble.documentfoundation.org/libreoffice-l10n-Workflow-based-on-master-tt4131453.html#a4132459
>> > [2] https://developer.gnome.org/hig-book/3.12/design-text-labels.html.en
>> >
>> > Cheers
>> > Sophie
>> >
>>
>>
>> --
>> Sophie Gautier sophie.gautier at documentfoundation.org
>> Tel:+33683901545
>> Co-founder - Release coordinator
>> The Document Foundation
>>
>> --
>> To unsubscribe e-mail to: l10n+unsubscribe at 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
>>
>
> --
> To unsubscribe e-mail to: l10n+unsubscribe at 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


More information about the LibreOffice mailing list