[libreoffice-l10n] Re: l10n process, en_US version, Help files
On Wed, 2013-12-11 at 17:19 +0100, Sophie wrote: Hi all, This mail is posted to the dev list and the l10n list, please follow up on the l10n list. I would like to open a discussion on the l10n workflow, the quality of the en_US version and the Help files. All is linked and I would like to discuss how we can improve the process here. I'm sure that having a better understanding between the l10n process and the dev process should help us to improve things :) So here is a proposal, it's a bit long, sorry for that. *Before updating Pootle: - it's important for l10n team to know the approx load of work that will be needed to achieve the whole work. Time between beta1 and rc1 is short and that will help to better organize this time between translation and proof reading. - depending also on the type of changes, we could use different tools to optimize the work. *When the l10n start: - we need a continuous communication and a planing of the updates made in Pootle, those translating off line are always frightened to lose something in the run. - it's exhausting when you think you are over and to see a new bunch of words coming. Knowing it in advance help to manage the time too *After RC1 and l10n integration - we need to know when integration is made after our fixes, there is currently no communication on this == for these three items, I have asked today to Andras and Christian how we can put that in place and where I can help them to do so, knowing also that Christian is managing this part almost alone now. *About the en_US overall quality - the process to rely on the l10n team to fix the en_US version is ok, even if it gives us extra work to understand what is meant before we realized it's a mistake. So it's also error prone for all the translations. - but that doesn't solve the several typos that already exist and that are overlooked by the l10n team (e.g in the Character Font Effect dialog, there is Overline _c_olor and Underline _C_olor and this is the same for several dialogs) - that doesn't solve also the lack of universal vocabulary used in several dialogs (e.g Tab/Pane/Panel/Deck to name the same object or Graphic/Picture/Image). I've nothing to propose here but to define a glossary where developers could pick the good word but I'm not sure it will be used * About the help files - I always wonder why there is a Help button on a new dialog when no help file is appended ;) One thing that we could with the new .ui file format is to confirm if each dialog actually has a help entry for it. There is an easy hack at https://bugs.freedesktop.org/show_bug.cgi?id=67350 to extract out the new-format helpids from the help and determine if they actually exist. That would weed out typos where the help gets detached from the thing it documents. Similarly someone could script if each new-format dialog has a help entry and make a list of stuff that is missing help and turn those into a list of tasks to document those things. Another thing that could be automated is to generate a skeleton help page from a new-format dialog. i.e. generate the help ids bookmarks for the interactive widgets, buttons, checkboxes, etc. and have fill-me-in headings and bodytext. C. -- 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
Re: [libreoffice-l10n] Re: l10n process, en_US version, Help files
On 2013.12.12. 0:35, Robinson Tryon wrote: On Wed, Dec 11, 2013 at 11:19 AM, Sophie gautier.sop...@gmail.com wrote: *After RC1 and l10n integration - we need to know when integration is made after our fixes, there is currently no communication on this Perhaps documenting the process in some pages on the wiki would help i10n better-understand how this works, and lead to some simple ways to better communicate what's going on elsewhere back to the i10n teams. There is the http://wiki.documentfoundation.org/ReleasePlan Tag is usually made on Tuesday. So translation commit happens about a day before that, let's say on Monday. So your fixes from Sunday will be in. This is how it worked, when I did this job, and AFAIK Cloph does the same. Best regards, Andras -- 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-l10n] Re: l10n process, en_US version, Help files
Hi Andras, all, Le 12/12/2013 11:18, Andras Timar a écrit : On 2013.12.11. 17:19, Sophie wrote: *About the en_US overall quality - the process to rely on the l10n team to fix the en_US version is ok, even if it gives us extra work to understand what is meant before we realized it's a mistake. So it's also error prone for all the translations. Discissions in this mailing list usually helped to clarify the meaning. Failing that, git log / git blame -- find out who the author was and ask him or her. Translators are welcome to test new features, sometimes it is obvious what a function does, despite the confusing UI text. and sometimes not because you may also translate the product without being an experienced user, or simply because you use Writer but not Calc, etc... - but that doesn't solve the several typos that already exist and that are overlooked by the l10n team (e.g in the Character Font Effect dialog, there is Overline _c_olor and Underline _C_olor and this is the same for several dialogs) If it's overlooked by 60+ active translation teams + beta testers, then probably it is not that much important. We can live with it. :) Not sure, as Khaled said, it may be because the load of work on translation is enough to not take care of other things. * About the help files - I always wonder why there is a Help button on a new dialog when no help file is appended ;) Probably it is prescribed by some rule, e.g. Gnome HIG, that every dialog must have a Help button. So dialog creator application puts it there, and the developer leaves it there thinking that someone may write a help page for it later. Well, may be, but unfortunately the help page is never created. - more and more functions are undocumented or their help is obsolete. I always think that an undocumented function is lost for the user and a sad thing for a developer because his function will not be used as expected. As I wrote above, many functions/new dialogs are self-describing. I hated to translate Gnome help 10 years ago, which was full of sentences like this: Click on Close button to close the dialog. So we need to limit the scope here. It would be good, if you could give examples, what needs further clarification in help. They may be self describing for you, but not for most of our users. I've collected some issues where the help needs to be amended or is missing, but it would be better to have a general process and try to include more people in it. May be, but I don't know how heavy it would be for developers, the solution would be to open an issue with a special tag like NF for each new feature, with three lines about what the feature is supposed to do. Searching on BZ with this special tag would allow to involve more people in the loop to test it and document it. The problem is that you cannot enforce any rule to developers. You can write a mail to the list, newcomers will not see it. You can write wiki pages, some people will not read it. You can ask people individually, some will ignore you. That I know :) But I have an idea. What about prolonging the string freeze date of help until the first bug fix release? That would give developers/help authors/translators more time to concentrate on documentation of new features. So we could say, with x.y.0 you get all new features, and x.y.1 will come with updated help. That's a good idea, but we still need help authors. I'm sure some people will jump in, even earlier, if they only know where, hence the proposal for a dedicated issue. As I said in another mail, I don't want to add more processes, rules, etc. But there is some areas that impact more than one team where it would be good to have some worflows. Cheers Sophie -- 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-l10n] Re: l10n process, en_US version, Help files
Hi Sophie, *, On Wed, Dec 11, 2013 at 5:19 PM, Sophie gautier.sop...@gmail.com wrote: [...] *Before updating Pootle: - it's important for l10n team to know the approx load of work that will be needed to achieve the whole work. Time between beta1 and rc1 is short and that will help to better organize this time between translation and proof reading. - depending also on the type of changes, we could use different tools to optimize the work. Don't think this applies to a new minor version, as a new project is created, the old one just renamed, so you immediately see in the new project how much work is left. And only with that info you can decide what meaningful way there is to minimize actual translation work. *When the l10n start: - we need a continuous communication and a planing of the updates made in Pootle, those translating off line are always frightened to lose something in the run. - it's exhausting when you think you are over and to see a new bunch of words coming. Knowing it in advance help to manage the time too Yes, of course, and let me reiterate: I did not update any templates in December. Whoever else did update them did so without prior notice. I fully agree that before templates are updated l10n teams should be warned. (but then again, I don't consider adding a new project as updating templates in this regard - if the new data is wrong, just copy from the old project, no loss, no additional work, no mixup with offline translations) *After RC1 and l10n integration - we need to know when integration is made after our fixes, there is currently no communication on this For every build it is the same: Translations are extracted from pootle on Tuesday and committed before tagging. Deadline for each tag is Monday. So if you add your changes on Monday, all is fine, your translations will be included. If you wait till Tuesday, your changes might be missed. The release schedule overview is available here: https://wiki.documentfoundation.org/ReleasePlan or more detailed for the next relevant releases: https://wiki.documentfoundation.org/ReleasePlan/4.2#4.2.0_release https://wiki.documentfoundation.org/ReleasePlan/4.1#4.1.5_release There you see the dates for the relevant releases, and also in the case of a new feature release the UI and string freeze dates. If you look at the 4.2.0 schedule, you see that English string freeze is next week (Monday, Dec 16) - so that is the week I did plan for updating the templates in pootle. I will grab the translations on Tuesday as for every build, (that way there is a copy of the transations in the sourcecode, in case something goes wrong with updating the templates), and after that would add the new templates to pootle for l10nprojects to update. Then l10n projects have a month to adapt to those late changes. == for these three items, I have asked today to Andras and Christian how we can put that in place and where I can help them to do so, knowing also that Christian is managing this part almost alone now. Yes, 4.2.0 was the first time I did update the projects in pootle, and I personally think it was not a huge desaster. There were two stumbling stones: 1) update_against_templates aborting because of added/renamed files 2) lots of changes in help that only affect metadata (the xml-tag attributes), not the actual translations first was causing only a fraction of the changes to show up, leading to the impression that almost nothing changes, and after that was fixed, the second one caused a huge string count to be displayed, probably making some translators think that suddenly their translations were deleted or something, since after 1) they thought they were almost finished. 2) was fixed with a script shortly afterwards, leaving only the real changes to process. Now what happened in December is a completely different story, esp. that kk project did end up having Greek translation is still a mystery, but not related to any updates. *About the en_US overall quality - [...] - but that doesn't solve the several typos that already exist and that are overlooked by the l10n team (e.g in the Character Font Effect dialog, Those that have been reported on the list have been fixed by Andras or me in the code - and people are very welcome to upload a patch to gerrit themselves. ( https://wiki.documentfoundation.org/Development/gerrit ) - that doesn't solve also the lack of universal vocabulary used in several dialogs (e.g Tab/Pane/Panel/Deck to name the same object or Graphic/Picture/Image). I've nothing to propose here but to define a glossary where developers could pick the good word but I'm not sure it will be used Graphic/Picture/Image is for example one of the changes that have already been somewhat unified for 4.2 - but yes, a terminology/glossary doesn't really exist. * About the help files [...] May be, but I don't know how heavy it would be for developers, the solution would be to open an issue with a special tag
Re: [libreoffice-l10n] Re: l10n process, en_US version, Help files
Hi *, On Wed, Dec 11, 2013 at 7:29 PM, Sophie gautier.sop...@gmail.com wrote: Le 11/12/2013 19:24, Thomas Hackert a écrit : [...] would this discussion not more suitable after the 4.2 release ;? Only answering your question: nope, because 4.3 is already on the radar, so that would be great to have something in place for it :) And of course memory is still fresh, so people remember what bugged them :-)) ciao Christian -- 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
Re: [libreoffice-l10n] Re: l10n process, en_US version, Help files
Hi Christian, On 2013.12.12. 13:56, Christian Lohmaier wrote: Yes, 4.2.0 was the first time I did update the projects in pootle, and I personally think it was not a huge desaster. There were two stumbling stones: 1) update_against_templates aborting because of added/renamed files 2) lots of changes in help that only affect metadata (the xml-tag attributes), not the actual translations And one issue remained, there are more files in the database, than actually needed, obsoleted files were not cleaned up (e.g. android/ folder). Now what happened in December is a completely different story, esp. that kk project did end up having Greek translation is still a mystery, but not related to any updates. And Greek has Kazakh fuzzies, as Dimitris reported yesterday: Why in the file of Greek sc/source/ui/src, I see so many Cyrillics with work needed? Was there a mistake? When I maintaned Pootle, I was also scared about possible database corruption, and since 2.5.0 we are experiencing mysterious server errors, e.g. when changing permissions on folders. TDF pays a monthly fee to Pootle devs for maintenance. I don't know, if you have worked with them, Christian. (I sent you a mail about Pootle 2.5.1 and/or Django update a few days ago.) Cheers, Andras -- 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
Re: [libreoffice-l10n] Re: l10n process, en_US version, Help files
Hi Christian, Le 12/12/2013 13:56, Christian Lohmaier a écrit : Hi Sophie, *, On Wed, Dec 11, 2013 at 5:19 PM, Sophie gautier.sop...@gmail.com wrote: [...] *Before updating Pootle: - it's important for l10n team to know the approx load of work that will be needed to achieve the whole work. Time between beta1 and rc1 is short and that will help to better organize this time between translation and proof reading. - depending also on the type of changes, we could use different tools to optimize the work. Don't think this applies to a new minor version, as a new project is created, the old one just renamed, so you immediately see in the new project how much work is left. And only with that info you can decide what meaningful way there is to minimize actual translation work. That doesn't apply to minor version, but for major version where we have only few new strings and the rest is xml manipulations. I've discovered that translation tools handle this very differently so knowing before the new strings versus what we have already in our TM or commented in the po files, etc... imho would help. But this may be simply not possible for you, I'm not enough technical to know, which is why I ask :) *When the l10n start: - we need a continuous communication and a planing of the updates made in Pootle, those translating off line are always frightened to lose something in the run. - it's exhausting when you think you are over and to see a new bunch of words coming. Knowing it in advance help to manage the time too Yes, of course, and let me reiterate: I did not update any templates in December. Whoever else did update them did so without prior notice. I fully agree that before templates are updated l10n teams should be warned. (but then again, I don't consider adding a new project as updating templates in this regard - if the new data is wrong, just copy from the old project, no loss, no additional work, no mixup with offline translations) Yes, and again, this is discussion is by no mean to point somebody mistake, but only to enhance our process and our communication. *After RC1 and l10n integration - we need to know when integration is made after our fixes, there is currently no communication on this For every build it is the same: Translations are extracted from pootle on Tuesday and committed before tagging. Deadline for each tag is Monday. So if you add your changes on Monday, all is fine, your translations will be included. If you wait till Tuesday, your changes might be missed. The release schedule overview is available here: https://wiki.documentfoundation.org/ReleasePlan or more detailed for the next relevant releases: https://wiki.documentfoundation.org/ReleasePlan/4.2#4.2.0_release https://wiki.documentfoundation.org/ReleasePlan/4.1#4.1.5_release There you see the dates for the relevant releases, and also in the case of a new feature release the UI and string freeze dates. If you look at the 4.2.0 schedule, you see that English string freeze is next week (Monday, Dec 16) - so that is the week I did plan for updating the templates in pootle. I will grab the translations on Tuesday as for every build, (that way there is a copy of the transations in the sourcecode, in case something goes wrong with updating the templates), and after that would add the new templates to pootle for l10nprojects to update. Then l10n projects have a month to adapt to those late changes. Ok, I'll add this to our l10n pages so new comers know how it works. == for these three items, I have asked today to Andras and Christian how we can put that in place and where I can help them to do so, knowing also that Christian is managing this part almost alone now. Yes, 4.2.0 was the first time I did update the projects in pootle, and I personally think it was not a huge desaster. me too, be sure and thanks a lot for your work :) There were two stumbling stones: 1) update_against_templates aborting because of added/renamed files 2) lots of changes in help that only affect metadata (the xml-tag attributes), not the actual translations first was causing only a fraction of the changes to show up, leading to the impression that almost nothing changes, and after that was fixed, the second one caused a huge string count to be displayed, probably making some translators think that suddenly their translations were deleted or something, since after 1) they thought they were almost finished. 2) was fixed with a script shortly afterwards, leaving only the real changes to process. ok, thank you for the details Now what happened in December is a completely different story, esp. that kk project did end up having Greek translation is still a mystery, but not related to any updates. *About the en_US overall quality - [...] - but that doesn't solve the several typos that already exist and that are overlooked by the l10n team (e.g in the Character Font
[libreoffice-l10n] Re: l10n process, en_US version, Help files
Hello Sophie, *, On Mittwoch, 11. Dezember 2013 17:19 Sophie wrote: snip I would like to open a discussion on the l10n workflow, the quality of the en_US version and the Help files. All is linked and I would like to discuss how we can improve the process here. I'm sure that having a better understanding between the l10n process and the dev process should help us to improve things :) So here is a proposal, it's a bit long, sorry for that. would this discussion not more suitable after the 4.2 release ;? *Before updating Pootle: - it's important for l10n team to know the approx load of work that will be needed to achieve the whole work. Time between beta1 and rc1 is short and that will help to better organize this time between translation and proof reading. +1 snip - it's exhausting when you think you are over and to see a new bunch of words coming. Knowing it in advance help to manage the time too +1 snip *About the en_US overall quality - the process to rely on the l10n team to fix the en_US version is ok, even if it gives us extra work to understand what is meant before we realized it's a mistake. So it's also error prone for all the translations. - but that doesn't solve the several typos that already exist and that are overlooked by the l10n team (e.g in the Character Font Effect dialog, there is Overline _c_olor and Underline _C_olor and this is the same for several dialogs) Do not forget the double/triple/howmuchelse used mnemonics in the UI ... ;) - that doesn't solve also the lack of universal vocabulary used in several dialogs (e.g Tab/Pane/Panel/Deck to name the same object or Graphic/Picture/Image). I've nothing to propose here but to define a glossary where developers could pick the good word but I'm not sure it will be used Yes, that would be really nice (especially, if we as translators would get it as well ... ;) ). It is really time consuming, what is meant with word $X and then finding out, that word $Y was used on other places ... :( * About the help files - I always wonder why there is a Help button on a new dialog when no help file is appended ;) And me is wondering, why there is not only a help button but also a help menu (as I am still a victim of https://bugs.freedesktop.org/show_bug.cgi?id=72022, I am not sure, if there should be any difference between the two ... :( ). Both opens konqueror on my system, although I have installed the OLH ... :( - more and more functions are undocumented or their help is obsolete. I always think that an undocumented function is lost for the user and a sad thing for a developer because his function will not be used as expected. May be, but I don't know how heavy it would be for developers, the solution would be to open an issue with a special tag like NF for each new feature, with three lines about what the feature is supposed to do. Searching on BZ with this special tag would allow to involve more people in the loop to test it and document it. Yes, please :) I also would like to see a short description for new function, that shortly explains it (and maybe a short example for it documented there as well) ... ;) Thanks for your mail Thomas. -- God is dead and I don't feel all too well either -- Ralph Moonen -- 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
Re: [libreoffice-l10n] Re: l10n process, en_US version, Help files
Le 11/12/2013 19:24, Thomas Hackert a écrit : Hello Sophie, *, On Mittwoch, 11. Dezember 2013 17:19 Sophie wrote: snip I would like to open a discussion on the l10n workflow, the quality of the en_US version and the Help files. All is linked and I would like to discuss how we can improve the process here. I'm sure that having a better understanding between the l10n process and the dev process should help us to improve things :) So here is a proposal, it's a bit long, sorry for that. would this discussion not more suitable after the 4.2 release ;? Only answering your question: nope, because 4.3 is already on the radar, so that would be great to have something in place for it :) Cheers Sophie -- 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-l10n] Re: l10n process, en_US version, Help files
On Wed, Dec 11, 2013 at 11:19 AM, Sophie gautier.sop...@gmail.com wrote: Hi all, This mail is posted to the dev list and the l10n list, please follow up on the l10n list. I would like to open a discussion on the l10n workflow, the quality of the en_US version and the Help files. All is linked and I would like to discuss how we can improve the process here. I'm sure that having a better understanding between the l10n process and the dev process should help us to improve things :) So here is a proposal, it's a bit long, sorry for that. Hiya Sophie, I've registered for the Pootle site, and I've started to poke around on there. I'm not sure if there's anything I can do at that point in the chain -- I guess I'll have to go up one level to the help and core repos? If there's anything specific I can do re: the en_US stuff, please let me know. I've got a couple of airport layovers in my near future, so I'll have a bit of time to spend :-) *Before updating Pootle: - it's important for l10n team to know the approx load of work that will be needed to achieve the whole work. Time between beta1 and rc1 is short and that will help to better organize this time between translation and proof reading. - depending also on the type of changes, we could use different tools to optimize the work. I'm not exactly sure how we import data into pootle, but perhaps we could set up some kind of web visualization tool to show the current diff (in # of strings, # of words, etc..) between what's in the upstream repos and what's in pootle. Would that be helpful? *When the l10n start: - we need a continuous communication and a planing of the updates made in Pootle, those translating off line are always frightened to lose something in the run. - it's exhausting when you think you are over and to see a new bunch of words coming. Knowing it in advance help to manage the time too So basically - better communication - more lead-time before strings land in pootle *After RC1 and l10n integration - we need to know when integration is made after our fixes, there is currently no communication on this Perhaps documenting the process in some pages on the wiki would help i10n better-understand how this works, and lead to some simple ways to better communicate what's going on elsewhere back to the i10n teams. *About the en_US overall quality - the process to rely on the l10n team to fix the en_US version is ok, even if it gives us extra work to understand what is meant before we realized it's a mistake. So it's also error prone for all the translations. I'm still getting my feet wet here, so I'm not quite as up to speed on this process as you guys. It sounds like some of these issues are rather nuanced, such that me being fluent in English isn't necessarily going to help me track down problems much faster without some additional context, right? - but that doesn't solve the several typos that already exist and that are overlooked by the l10n team (e.g in the Character Font Effect dialog, there is Overline _c_olor and Underline _C_olor and this is the same for several dialogs) What's our current workflow for solving those? Filing a bug, or? - that doesn't solve also the lack of universal vocabulary used in several dialogs (e.g Tab/Pane/Panel/Deck to name the same object or Graphic/Picture/Image). I've nothing to propose here but to define a glossary where developers could pick the good word but I'm not sure it will be used Do we have a dialog with labels on all of the different parts, indicating what nomenclature we're using to refer to each dialog or component? Here's an example with a car dashboard: http://12v.org/urs/EuroUrS6InstrumentClusterDiagram.jpg Perhaps something like that would help the devs keep the naming consistent? Cheers, --R -- 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
