Re: [libreoffice-l10n] Re: Workflow between dev, UX and l10n teams
On 28.01.2015 03:14, Jesper Hertel wrote: 2015-01-28 2:59 GMT+01:00 Robinson Tryon bishop.robin...@gmail.com mailto:bishop.robin...@gmail.com: 2) What will the language be for builds w/o langpacks? Just a generic 'English'? (maybe we can call it LibreOffice English :-) Maybe there should be no such build at all. perhaps it would be possible to identify the strings by integers and produce en-US translations from that via the l10n tooling... ... but there has to be a default language, otherwise developers will become grumpy because builds will take longer and use more disk space; the translations git repository currently takes up 2GB, which is 40% more space than the source code (core) repo, (+ 1.5GB for the working copy), and is growing at a faster rate, so it is good that the translation repository is optional and only downloaded if you use --with-lang=... ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [libreoffice-l10n] Re: Workflow between dev, UX and l10n teams
Hi Jan, 2015.01.26 16:43, Jan Holesovsky rašė: Mihovil Stanić píše v Po 26. 01. 2015 v 10:25 +0100: Cosmetic changes (~ to _ or Status to Status: or ... to … or those different quote styles I don't even have on my keyboard) and anything similliar - NOT OK if you don't script it for all languages Cosmetic changes (Big brown fox - Big Brown Fox) - NOT OK at all, change just for en_us, don't change my strings and don't even notify me you did it in en_us I see 2 problems here: 1) There is no tool that would detect these trivial changes, and would act accordingly. Regarding 1) - I thought that Pootle is detecting the trivial changes some way, and offering the original translation. Is it not? What can be done to improve that, so that for translators it is just a matter of checking; not a matter of translating? [Or even what you suggest - that it would just update the source strings without touching the translations?] Pootle does offer the original translation, but the localizer still has to approve it. Furthermore, Pootle does not apply any automatic changes. If you had e.g. Some ~string, and you change it to Some _string, Pootle will show the original translation as a hint, but the user will still have to port this trivial change to the translation manually. Needless to say, sometimes these minor differences avoid being noticed by the localizers, which results in errors in the locale (I've seen incorrect access key identifiers in the menus at least once). However, while you are correct that there is no tool to detect these changes, I don't think there has to be. The person who implements the change knows better than anyone whether or not it can be automated, perhaps they even automated it themselves. For example, I seriously doubt that somebody went over all L10n files and changed triple dots to ellipses manually, this was most likely a scripted change. Same, or very similar, script would have probably worked with all other locales, but I guess that person simply didn't think about it. Similarly, changes in used quote characters most likely could have been isolated and transplanted to locales. Adding colons to certain strings only would probably have been slightly more difficult, but still scriptable. And none of that requires any tool to detect trivial changes... ;) 2) The texts for translations are updated in big 'code' drops, without possibility for translators to affect the process in any way - for them it is too late. Regarding 2) - I'm glad that you say that the strings will be now getting to Pootle immediately after the code / string changes in master. I think it is important that the translators will be able to deal with the changes immediately, not several months later, so that they can cooperate, and not only react. In general, I don't think that setting extremely strict rules works, unless you have means how to enforce them - like via a commit hook or so (and it is extremely unpopular way to do things). It is always much better to communicate - if you see a developer who commits a change that causes you grief, please _do_ tell _him/her_ immediately, and - if possible - in a friendly way. I'm sure he/she will do much better the next time. Unfortunately I did not see any signs of notice that this or that change was problematic for localization on the development mailing list - were there such warnings there? Like commit XY caused AB - please don't do such things, unless we agree how to do that effectively / without pain? Or was it impossible so far because the strings in Pootle were not synced with master? I fully agree with you here, and yes, so far communicating these issues was really difficult because these massive changes appeared in front of the localizers' eyes way too late in the process. Regards, Rimas ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [libreoffice-l10n] Re: Workflow between dev, UX and l10n teams
Hi Rimas, all Le 27 janv. 2015 19:32, Rimas Kudelis r...@akl.lt a écrit : Hi Jan, 2015.01.26 16:43, Jan Holesovsky rašė: Mihovil Stanić píše v Po 26. 01. 2015 v 10:25 +0100: Cosmetic changes (~ to _ or Status to Status: or ... to … or those different quote styles I don't even have on my keyboard) and anything similliar - NOT OK if you don't script it for all languages Cosmetic changes (Big brown fox - Big Brown Fox) - NOT OK at all, change just for en_us, don't change my strings and don't even notify me you did it in en_us I see 2 problems here: 1) There is no tool that would detect these trivial changes, and would act accordingly. Regarding 1) - I thought that Pootle is detecting the trivial changes some way, and offering the original translation. Is it not? What can be done to improve that, so that for translators it is just a matter of checking; not a matter of translating? [Or even what you suggest - that it would just update the source strings without touching the translations?] Pootle does offer the original translation, but the localizer still has to approve it. Furthermore, Pootle does not apply any automatic changes. If you had e.g. Some ~string, and you change it to Some _string, Pootle will show the original translation as a hint, but the user will still have to port this trivial change to the translation manually. Needless to say, sometimes these minor differences avoid being noticed by the localizers, which results in errors in the locale (I've seen incorrect access key identifiers in the menus at least once). However, while you are correct that there is no tool to detect these changes, I don't think there has to be. The person who implements the change knows better than anyone whether or not it can be automated, perhaps they even automated it themselves. For example, I seriously doubt that somebody went over all L10n files and changed triple dots to ellipses manually, this was most likely a scripted change. Same, or very similar, script would have probably worked with all other locales, but I guess that person simply didn't think about it. Similarly, changes in used quote characters most likely could have been isolated and transplanted to locales. Adding colons to certain strings only would probably have been slightly more difficult, but still scriptable. And none of that requires any tool to detect trivial changes... ;) That's the point of this discussion, thanks Rimas to make it :-) L10n team can always react, and earlier now, but making the scripting part of the commit or part of the 'one making the change' is more natural in the workflow. In other words, our product is not en_US only. 2) The texts for translations are updated in big 'code' drops, without possibility for translators to affect the process in any way - for them it is too late. Regarding 2) - I'm glad that you say that the strings will be now getting to Pootle immediately after the code / string changes in master. I think it is important that the translators will be able to deal with the changes immediately, not several months later, so that they can cooperate, and not only react. In general, I don't think that setting extremely strict rules works, unless you have means how to enforce them - like via a commit hook or so (and it is extremely unpopular way to do things). It is always much better to communicate - if you see a developer who commits a change that causes you grief, please _do_ tell _him/her_ immediately, and - if possible - in a friendly way. I'm sure he/she will do much better the next time. Unfortunately I did not see any signs of notice that this or that change was problematic for localization on the development mailing list - were there such warnings there? Like commit XY caused AB - please don't do such things, unless we agree how to do that effectively / without pain? Or was it impossible so far because the strings in Pootle were not synced with master? I fully agree with you here, and yes, so far communicating these issues was really difficult because these massive changes appeared in front of the localizers' eyes way too late in the process. What we should take care though is to not over complicate the work of l10n team by relying on this fact. So as I already said, it should be a shared work and vigilance by the concerned teams. Cheers Sophie ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [libreoffice-l10n] Re: Workflow between dev, UX and l10n teams
Þann mán 26.jan 2015 09:25, skrifaði Mihovil Stanić: Not sure what can we add here? You summed it up nicely in those 3 points. As far as I'm concerned, en_us can be changed/improved as much as anyone wants... only if they provide script for automatic update for all other affected languages. New strings - OK Edited strings with changed meaning, fixed typos - OK Cosmetic changes (~ to _ or Status to Status: or ... to … or those different quote styles I don't even have on my keyboard) and anything similliar - NOT OK if you don't script it for all languages Cosmetic changes (Big brown fox - Big Brown Fox) - NOT OK at all, change just for en_us, don't change my strings and don't even notify me you did it in en_us May I add here: XML/HTML entities and such (a href... to link) - NOT OK, scripted for all languages (if possible) Sveinn í Felli Mihovil 26.01.2015 u 09:33, Sophie je napisao/la: 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. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [libreoffice-l10n] Re: Workflow between dev, UX and l10n teams
Not sure what can we add here? You summed it up nicely in those 3 points. As far as I'm concerned, en_us can be changed/improved as much as anyone wants... only if they provide script for automatic update for all other affected languages. New strings - OK Edited strings with changed meaning, fixed typos - OK Cosmetic changes (~ to _ or Status to Status: or ... to … or those different quote styles I don't even have on my keyboard) and anything similliar - NOT OK if you don't script it for all languages Cosmetic changes (Big brown fox - Big Brown Fox) - NOT OK at all, change just for en_us, don't change my strings and don't even notify me you did it in en_us Mihovil 26.01.2015 u 09:33, Sophie je napisao/la: 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. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [libreoffice-l10n] Re: Workflow between dev, UX and l10n teams
2015-01-28 2:59 GMT+01:00 Robinson Tryon bishop.robin...@gmail.com: 2) What will the language be for builds w/o langpacks? Just a generic 'English'? (maybe we can call it LibreOffice English :-) Maybe there should be no such build at all. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [libreoffice-l10n] Re: Workflow between dev, UX and l10n teams
2015-01-27 16:09 GMT+01:00 Michael Bauer f...@akerbeltz.org: PS the current setup is not foolproof either as we sometimes get really bad strings, linguistically bad that is. If this is such a concern, then why don't we set up a panel of experiences localizers who are willing to help developers judge if a change is semantic or cosmetic before we land them on l10n in general? Michael +1 to both your comments, Michael. Sgrìobh Jan Holesovsky na leanas 27/01/2015 aig 14:16: be deciding if a change should be applied in the sources (ie. it is a change needed for all languages) and what is just making the original more consistent? And again - what to do if the person mis-judges? And thank you to you, Kendy (aka Jan Holesovsky), for answering my why. I do see that it is a complex matter. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [libreoffice-l10n] Re: Workflow between dev, UX and l10n teams
2015-01-28 2:59 GMT+01:00 Robinson Tryon bishop.robin...@gmail.com: 1) will inconsistency of nouns (e.g. color vs. colour), inconsistency of grammar, etc.. within the sources in master make translation harder for the native-lang teams? Not if they use Pootle and set up additional language sources. Then they can use any translated language they want as a source, e.g. the translated en-US or en-UK (or whatever the British version is called). But offline translators might not have that option? ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [libreoffice-l10n] Re: Workflow between dev, UX and l10n teams
Hi Jesper, Jesper Hertel píše v Út 27. 01. 2015 v 14:08 +0100: That's why we were thinking of a en_US version as a real language and different from the sources and But at some stage this will have to apply to the sources Why? Because the sources are the ultimate version of the strings. Who would be deciding if a change should be applied in the sources (ie. it is a change needed for all languages) and what is just making the original more consistent? And again - what to do if the person mis-judges? All the best, Kendy ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [libreoffice-l10n] Re: Workflow between dev, UX and l10n teams
A person who cannot decide if a string change is semantic or cosmetic to en-US should not be messing around with the string names in the first place, if you ask me. Ok so maybe occasionally they might get it wrong. That still produces a lot LESS workload to fix that landing 2000 cosmetic en-US changes on 50 locales. Not a good reason for opposing this approach. Michael Sgrìobh Jan Holesovsky na leanas 27/01/2015 aig 14:16: Because the sources are the ultimate version of the strings. Who would be deciding if a change should be applied in the sources (ie. it is a change needed for all languages) and what is just making the original more consistent? And again - what to do if the person mis-judges? All the best, Kendy -- *Akerbeltz http://www.faclair.com/* Goireasan Gàidhlig air an lìon Fòn: +44-141-946 4437 Facs: +44-141-945 2701 *Tha Gàidhlig aig a' choimpiutair agad, siuthad, feuch e!* Iomadh rud eadar prògraman oifis, brabhsairean, predictive texting, geamannan is mòran a bharrachd. Tadhail oirnn aig www.iGàidhlig.net http://www.iGaidhlig.net/ ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [libreoffice-l10n] Re: Workflow between dev, UX and l10n teams
PS the current setup is not foolproof either as we sometimes get really bad strings, linguistically bad that is. If this is such a concern, then why don't we set up a panel of experiences localizers who are willing to help developers judge if a change is semantic or cosmetic before we land them on l10n in general? Michael Sgrìobh Jan Holesovsky na leanas 27/01/2015 aig 14:16: be deciding if a change should be applied in the sources (ie. it is a change needed for all languages) and what is just making the original more consistent? And again - what to do if the person mis-judges? -- *Akerbeltz http://www.faclair.com/* Goireasan Gàidhlig air an lìon Fòn: +44-141-946 4437 Facs: +44-141-945 2701 *Tha Gàidhlig aig a' choimpiutair agad, siuthad, feuch e!* Iomadh rud eadar prògraman oifis, brabhsairean, predictive texting, geamannan is mòran a bharrachd. Tadhail oirnn aig www.iGàidhlig.net http://www.iGaidhlig.net/ ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [libreoffice-l10n] Re: Workflow between dev, UX and l10n teams
2015-01-26 16:40 GMT+01:00 Jan Holesovsky ke...@collabora.com: That's why we were thinking of a en_US version as a real language and different from the sources and But at some stage this will have to apply to the sources Why? ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [libreoffice-l10n] Re: Workflow between dev, UX and l10n teams
2015-01-28 2:59 GMT+01:00 Robinson Tryon bishop.robin...@gmail.com: 3) Who's going to step up to maintain en_US? (I'd love to help, but I'm working tons of hours as it is) There must be some American users of LibreOffice? Wouldn't en_US just be like any other language, with the same challenge of finding translators? Some would step up if they find the en_US translation to be less than acceptable for them. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [libreoffice-l10n] Re: Workflow between dev, UX and l10n teams
2015-01-26 12:15 GMT+01:00 Tom Davies tomc...@gmail.com: Hi :) Hi Tom! Yes that suggestion was put forwards in the previous thread Good! And thank you for telling me that. and i still think it is an excellent idea - or at least has a lot of merit. I absolutely agree ;-). I seem to remember there were excellent reasons why it might be unworkable 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. but i'm not sure if they really are total blockers. 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. 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? 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. 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. 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. [1]: https://translations.documentfoundation.org/accounts/edit/ Regards from Jesper 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
Re: [libreoffice-l10n] Re: Workflow between dev, UX and l10n teams
Hi :) Yeh i think Sophie did such a brilliant job of summarising all the points that no-one had anything to argue against. My main concern was about automating the bits that could be automated in some sensible way - preferably some way that each language could select to opt into or out of. In wiki-editing people are encouraged to write a summary, like a subject-line in an email, for changes beyond just a couple of characters. Something like that might help with the automation. I really liked the point about having some way of identifying trivial but frequent changes and minor grammer corrections that most translators will already have dealt with in order to make sense in their own language(s). There was a lot of other interesting things in Sophie's post but i just agree with all of them and that makes it difficult to discuss ;( It seems like just about everyone here feels the same way. Regards from Tom :) On 26 January 2015 at 09:32, Sveinn í Felli s...@fellsnet.is wrote: Þann mán 26.jan 2015 09:25, skrifaði Mihovil Stanić: Not sure what can we add here? You summed it up nicely in those 3 points. As far as I'm concerned, en_us can be changed/improved as much as anyone wants... only if they provide script for automatic update for all other affected languages. New strings - OK Edited strings with changed meaning, fixed typos - OK Cosmetic changes (~ to _ or Status to Status: or ... to … or those different quote styles I don't even have on my keyboard) and anything similliar - NOT OK if you don't script it for all languages Cosmetic changes (Big brown fox - Big Brown Fox) - NOT OK at all, change just for en_us, don't change my strings and don't even notify me you did it in en_us May I add here: XML/HTML entities and such (a href... to link) - NOT OK, scripted for all languages (if possible) Sveinn í Felli Mihovil 26.01.2015 u 09:33, Sophie je napisao/la: 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. -- 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
Re: [libreoffice-l10n] Re: Workflow between dev, UX and l10n teams
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 ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [libreoffice-l10n] Re: Workflow between dev, UX and l10n teams
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
