<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">2015-01-26 12:15 GMT+01:00 Tom Davies <span dir="ltr"><<a href="mailto:tomcecf@gmail.com" target="_blank">tomcecf@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Hi :)<br></blockquote><div><br></div><div>Hi Tom!</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Yes that suggestion was put forwards in the previous thread </blockquote><div><br></div><div>Good! And thank you for telling me that.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">and i still think it is an excellent idea - or at least has a lot of merit.<br></blockquote><div><br></div><div>I absolutely agree ;-).</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
I seem to remember there were excellent reasons why it might be<br>
unworkable </blockquote><div><br></div><div>I am curious to see those reasons. Guess I will have to browse through the discussion to find it. But it is rather long, so I might not do that right now. </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">but i'm not sure if they really are total blockers.<br></blockquote><div><br></div><div>I can't see how they could be total blockers. LibreOffice comes in hundreds of languages, so this would just be a new language like any other, and adding new languages has never seemed to be a big problem before.</div><div><br></div><div>There could even still be a language-simplistic version of LibreOffice with only the unpolished source code keys used and no translation to polished en-us (if anybody prefer such a version?), but people that want the language to be polished and correct would just pick up the en-us translation like everybody else picks up the translation for their own local language. Why should en-us have any special status in the construction of the final product?</div><div><br></div><div>It doesn't solve the problems with adding colons etc. to existing strings – changes like that should of course still be automated. But it would solve problems resulting from changes in style, correction of non-semantic typos, etc.</div><div><br></div><div>And everybody working in Pootle could still add the polished and correct en-us translation as one of their "alternative source languages" (you can do that in the settings [1]) and we could all therefore still use the polished, correct en-us translation as the basis of our translations if we prefer that over the more coarse, non-polished key strings from the source code.</div><div><br></div><div>Of course I might be repeating arguments that have already been stated in the earlier discussion. If anyone can find the right part of the original discussion (perhaps because they know what to search for because they remember the discussion) they are more than welcome to point it out to me.<br></div><div><br></div><div><div>[1]: <a href="https://translations.documentfoundation.org/accounts/edit/">https://translations.documentfoundation.org/accounts/edit/</a></div><div><br></div></div><div>Regards from </div><div>Jesper</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Regards from<br>
<span class=""><font color="#888888">Tom :)<br>
</font></span><div class=""><div class="h5"><br>
<br>
On 26 January 2015 at 10:52, Jesper Hertel <<a href="mailto:jesper.hertel@gmail.com">jesper.hertel@gmail.com</a>> wrote:<br>
> Hi Sophie and everybody else,<br>
><br>
> Well I didn't answer as I didn't feel like finding out what the "projects@<br>
> list" was and joining that list to be able to join the discussion there.<br>
><br>
> I will answer here.<br>
><br>
> I did not read the whole previous discussion but did anyone suggest to add<br>
> a new en-us translation language in Pootle and let that be the place where<br>
> all non-semantic changes to the en-us strings happen? That way the current<br>
> strings in the source code will turn into mere translation keys written in<br>
> en-us. The final en-us polishing will then happen in the translation files<br>
> just like any other language and will of course not affect any of the other<br>
> languages.<br>
><br>
> Any semantic change should of course still happen in the "keys", i.e. the<br>
> source code, but non-semantic changes should be prohibited there and<br>
> instead made in the en-us translation in Pootle.<br>
><br>
> This might be something obvious that you already talked a lot about, but I<br>
> just want to make sure this option isn't overlooked.<br>
><br>
> Jesper<br>
> Den 26/01/2015 09.34 skrev "Sophie" <<a href="mailto:gautier.sophie@gmail.com">gautier.sophie@gmail.com</a>>:<br>
><br>
>> Hi,<br>
>><br>
>> Resending as there was no answer to the proposals :)<br>
>> Cheers<br>
>> Sophie<br>
>> Le 19/01/2015 11:03, Sophie a écrit :<br>
>> > Hi all,<br>
>> ><br>
>> > [Please follow-up the discussion on projects@ list to keep the history<br>
>> > of the thread there and ease the discussion, thanks :-)]<br>
>> ><br>
>> > I would like to open a discussion about the way developers team, UX team<br>
>> > and l10n team should interact and work together.<br>
>> ><br>
>> > There has been a heavy discussion [see this thread 1] during this round<br>
>> > of translation. The l10n team was a bit frustrated that there were again<br>
>> > so many changes in the en_US version that does not concern the l10n<br>
>> > versions (like adding colon at the end or capitals in the middle of the<br>
>> > strings).<br>
>> ><br>
>> > Each time, it seems part of this could be automated or a reflection<br>
>> > on how to avoid messing the l10n work should have been introduced before<br>
>> > those changes are committed. For example, if I decide to change FR<br>
>> > localization to have sentence capitalization in the menu entries, none<br>
>> > of the 100 other localizations won't and shouldn't be affected. It<br>
>> > should be the same for en_US version or if really impossible, try to<br>
>> > find a solution that lower the impact on all localizations.<br>
>> ><br>
>> > None of the l10n teams is against changing or correcting the UI of the<br>
>> > en_US version and none is against the natural evolution of the suite.<br>
>> > What is not bearable is when you have 100 000 changes in en_US and only<br>
>> > a 1/3 concerns all the other languages and it is repeated over the<br>
>> > branches.<br>
>> ><br>
>> > We are trying to change our workflow to work on master instead of<br>
>> > branches. That will allow us to review the strings earlier (to leverage<br>
>> > heavy unneeded changes if possible) and have more time to localize. But<br>
>> > that will work only if each taking part of the changes take care of the<br>
>> > others.<br>
>> ><br>
>> > To conclude, what l10n team would like to see is:<br>
>> > - a review process of the strings before they are committed and make<br>
>> > sure they respect the en_US standards (capitals, grammar, punctuation,<br>
>> > typography). Maybe adding the Gnome HIG book to our pages [like 2] if<br>
>> > not already.<br>
>> ><br>
>> > - if there is a way to script changes, script them otherwise wait until<br>
>> > there is a script available to commit them<br>
>> ><br>
>> > - any time there are heavy changes that pop up in someone's mind (like<br>
>> > changing ... for …) discuss it with the l10n team before committing<br>
>> > those changes.<br>
>> ><br>
>> > I know it may lower the enthusiasm of some contributors, but it will<br>
>> > regain the one of our l10n teams for sure :)<br>
>> ><br>
>> ><br>
>> > [1]<br>
>> ><br>
>> <a href="http://nabble.documentfoundation.org/libreoffice-l10n-Workflow-based-on-master-tt4131453.html#a4132459" target="_blank">http://nabble.documentfoundation.org/libreoffice-l10n-Workflow-based-on-master-tt4131453.html#a4132459</a><br>
>> > [2] <a href="https://developer.gnome.org/hig-book/3.12/design-text-labels.html.en" target="_blank">https://developer.gnome.org/hig-book/3.12/design-text-labels.html.en</a><br>
>> ><br>
>> > Cheers<br>
>> > Sophie<br>
>> ><br>
>><br>
>><br>
>> --<br>
>> Sophie Gautier <a href="mailto:sophie.gautier@documentfoundation.org">sophie.gautier@documentfoundation.org</a><br>
>> Tel:+33683901545<br>
>> Co-founder - Release coordinator<br>
>> The Document Foundation<br>
>><br>
>> --<br>
>> To unsubscribe e-mail to: <a href="mailto:l10n%2Bunsubscribe@global.libreoffice.org">l10n+unsubscribe@global.libreoffice.org</a><br>
>> Problems?<br>
>> <a href="http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/" target="_blank">http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/</a><br>
>> Posting guidelines + more: <a href="http://wiki.documentfoundation.org/Netiquette" target="_blank">http://wiki.documentfoundation.org/Netiquette</a><br>
>> List archive: <a href="http://listarchives.libreoffice.org/global/l10n/" target="_blank">http://listarchives.libreoffice.org/global/l10n/</a><br>
>> All messages sent to this list will be publicly archived and cannot be<br>
>> deleted<br>
>><br>
><br>
> --<br>
> To unsubscribe e-mail to: <a href="mailto:l10n%2Bunsubscribe@global.libreoffice.org">l10n+unsubscribe@global.libreoffice.org</a><br>
> Problems? <a href="http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/" target="_blank">http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/</a><br>
> Posting guidelines + more: <a href="http://wiki.documentfoundation.org/Netiquette" target="_blank">http://wiki.documentfoundation.org/Netiquette</a><br>
> List archive: <a href="http://listarchives.libreoffice.org/global/l10n/" target="_blank">http://listarchives.libreoffice.org/global/l10n/</a><br>
> All messages sent to this list will be publicly archived and cannot be deleted<br>
</div></div></blockquote></div><br></div></div>