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.her...@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.sop...@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.gaut...@documentfoundation.org >> Tel:+33683901545 >> Co-founder - Release coordinator >> The Document Foundation >> >> -- >> To unsubscribe e-mail to: l10n+unsubscr...@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+unsubscr...@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 _______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
