[libreoffice-projects] 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? -- To unsubscribe e-mail to: projects+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/projects/ All messages sent to this list will be publicly archived and cannot be deleted
Re: [libreoffice-projects] Workflow between dev, UX and l10n teams
Hi Robinson On 26/01/2015 10:06, Robinson Tryon wrote: On Mon, Jan 26, 2015 at 6:48 AM, Olivier Hallot olivier.hal...@libreoffice.org wrote: On 19/01/2015 08:03, Sophie wrote: 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. That will require a revisor with en_US skills. About how much work (read: time) would this review process entail? Thanks, --R If you need to review *all* help UI, I think it maps to an equivalent of a 500 or more page handbook. -- Olivier Hallot Comunidade LibreOffice http://ask.libreoffice.org/pt-br -- To unsubscribe e-mail to: projects+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/projects/ All messages sent to this list will be publicly archived and cannot be deleted
[libreoffice-projects] 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 -- To unsubscribe e-mail to: projects+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/projects/ All messages sent to this list will be publicly archived and cannot be deleted
Re: [libreoffice-projects] Re: Workflow between dev, UX and l10n teams
Hi, 2015.01.26 17:40, Jan Holesovsky rašė: Sophie píše v Po 26. 01. 2015 v 16:19 +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 - and at that time, it will be even worse than now :-( I'm afraid having en_US as a separate language will make the situation worse, not better. also about scripting changes when possible (like the substitution of ~ by _) Sure - so I think this was something that could have been automatized with a trivial script; when this was noticed for the first time, please? Pity that it was not brought to the ESC as a problem... I just wanted to say that I'm fully with Jan on these two statements: I believe that the right thing to do is automation of massive trivial changes, not a separate pseudo-locale where strings with developer mistakes and/or without enough clarity would be carved in stone. Having that pseudo-locale would not help us solve half of cosmetic issues, such as added colons or changed access keys, these would require scripting anyway. The issues it would solve are either also scriptable (typographical or letter case changes) or should be rare by their nature (typo fixes or sentence improvements; now that some teams work on master, these should occur in branches even less frequently). On the other hand, having that source locale would introduce a yet another level of complexity by forcing each developer to decide where each string change should go, and if you are thinking about making a single person or two accountable for these decisions, then why not ask them to instead review strings that are about to be landed into en-US? In general, I think it's kind of sloppy (sorry, can't think of a right word right now) to leave miss-worded strings in the source as they are, and fix them in a separate locale instead. I don't know how many fixes like that (specifically excluding typography, colons and similar massive replacements) end up in each release, but assuming there aren't many (e.g. a dozen or two), I really don't think they deserve all this fuss. Regards, Rimas -- To unsubscribe e-mail to: projects+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/projects/ All messages sent to this list will be publicly archived and cannot be deleted
[libreoffice-projects] 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 -- To unsubscribe e-mail to: projects+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/projects/ All messages sent to this list will be publicly archived and cannot be deleted
Re: [libreoffice-projects] Workflow between dev, UX and l10n teams
On Tue, Jan 27, 2015 at 4:15 PM, jonathon toki.kant...@gmail.com wrote: On 27/01/15 18:36, Rimas Kudelis wrote: If you need to review *all* help UI, I think it maps to an equivalent of a 500 or more page handbook. But you don't. L10n only are only asking for review of strings when they are being changed. Review strings in context. Whoever volunteers for this task will need to go through _all_ of the existing help, UI, and other things, before reviewing strings when they are changed. So basically there's a steep learning curve, but once someone has an active knowledge of the current text, then they should be able to do work in small deltas. As long as there's clear documentation about getting up to speed (and the potential time to do so), the workflow seems plausible. The task requires: * Copy editing; * Line editing; * Proof reading; amongst other editing tasks. Yup, sounds challenging. FWIW, this also means that the l10n, a11y, and i18n teams will be dumped with a slew of changes that might, but probably won't affect their existing translation, but will still need to be verified to ensure that their translations, etc. are not broken. I keep on hearing about these big changes. Some of them sound scriptable, but have there been some that are not? Aside from the bulk-changes, how many string additions/modifications/etc.. are there on a weekly or monthly basis? BTW, does anybody know where the *current* _LibreOffice Manual of Style_ can be obtained from? Once we find it, let's add a redirect here: https://wiki.documentfoundation.org/Manual_of_style (Or it can live there, if it doesn't have a good home yet! :-) If it's more of an official-ish document, perhaps this would be a better home: https://wiki.documentfoundation.org/TDF/Manual_of_style Best, --R -- Robinson Tryon QA Engineer - The Document Foundation LibreOffice Community Outreach Herald qu...@libreoffice.org -- To unsubscribe e-mail to: projects+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/projects/ All messages sent to this list will be publicly archived and cannot be deleted
[libreoffice-projects] 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/ -- To unsubscribe e-mail to: projects+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/projects/ All messages sent to this list will be publicly archived and cannot be deleted
Re: [libreoffice-projects] Workflow between dev, UX and l10n teams
Hi again, On 2015 m. sausio 28 d. 09:09:27 EET, Rimas Kudelis r...@akl.lt wrote: On 2015 m. sausio 28 d. 08:10:38 EET, jonathon toki.kant...@gmail.com wrote: BTW, when you say style guide, which specific one do you mean? The one you're looking for, assuming it exists. If not, or could be a combination of Gnome HIG and any American English style guide we (the LibO community) would deem acceptable and meeting our needs (e.g. The Chicago Manual of Style). In fact, I just thought that it doesn't even have to be a formal manual: if somebody would be willing to oversee style consistency in our strings, and that style would look acceptable by our en-US users, then why not? Especially if that person would be willing to formalize these rules into a written style manual along the way. -- Rimas -- To unsubscribe e-mail to: projects+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/projects/ All messages sent to this list will be publicly archived and cannot be deleted
Re: [libreoffice-projects] Workflow between dev, UX and l10n teams
On Wed, Jan 28, 2015 at 5:22 PM, Rimas Kudelis r...@akl.lt wrote: Hi again, On 2015 m. sausio 28 d. 09:09:27 EET, Rimas Kudelis r...@akl.lt wrote: On 2015 m. sausio 28 d. 08:10:38 EET, jonathon toki.kant...@gmail.com wrote: BTW, when you say style guide, which specific one do you mean? The one you're looking for, assuming it exists. If not, or could be a combination of Gnome HIG and any American English style guide we (the LibO community) would deem acceptable and meeting our needs (e.g. The Chicago Manual of Style). In fact, I just thought that it doesn't even have to be a formal manual: if somebody would be willing to oversee style consistency in our strings, and that style would look acceptable by our en-US users, then why not? Especially if that person would be willing to formalize these rules into a written style manual along the way. -- Rimas This document may be of interest: https://obriend.fedorapeople.org/WritingStyleGuide/ It's only recently (last year) been open sourced and made public. On the Docs list, I wrote: Here is one I remember from OOo: https://wiki.openoffice.org/wiki/Documentation/Dashboard/Help_Style_Guide There is also a short (and somewhat out of date) writing style guide for LO user guides. It is Chapter 5 in the LO Docs Contributors Guide. See here: https://wiki.documentfoundation.org/Documentation/Development#Contributors_Guide In Docs, we mainly referred to the relevant sections of _Read Me First! A Style Guide for the Computer Industry_ by Sun Technical Publications. --Jean -- To unsubscribe e-mail to: projects+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/projects/ All messages sent to this list will be publicly archived and cannot be deleted
Re: [libreoffice-projects] Workflow between dev, UX and l10n teams
Hi Jonathon, 2015.01.27 23:15, jonathon wrote: On 27/01/15 18:36, Rimas Kudelis wrote: If you need to review *all* help UI, I think it maps to an equivalent of a 500 or more page handbook. But you don't. L10n only are only asking for review of strings when they are being changed. Review strings in context. Whoever volunteers for this task will need to go through _all_ of the existing help, UI, and other things, before reviewing strings when they are changed. The task requires: * Copy editing; * Line editing; * Proof reading; amongst other editing tasks. FWIW, this also means that the l10n, a11y, and i18n teams will be dumped with a slew of changes that might, but probably won't affect their existing translation, but will still need to be verified to ensure that their translations, etc. are not broken. I really don't see a revision of all existing strings as a requirement to start reviewing newly added ones. Of course, it would be beneficial, but not at all a requirement. You don't need to read a 500-pages worth of text to tell whether or not a certain string is clear, concise and grammatically, syntactically and typographically correct. Especially if you are a native English speaker and have a style guide at hand. Rimas -- To unsubscribe e-mail to: projects+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/projects/ All messages sent to this list will be publicly archived and cannot be deleted
