Re: l10n process, en_US version, Help files
Hello Old thread revival ! Le Fri, 13 Dec 2013 10:01:05 +0100, Sophie gautier.sop...@gmail.com a écrit: * And... fixing ! Easy hacks or l10n sessions to fix that are both valid choices. We may want to automate finding occurrences of text in the code. We began with fdo#39439, but further steps are required. did you submit your work, is it now integrated? So... I started with hrc and src files to end with .ui files, so it took longer than expected. I managed to deliver the small site to openshift. It was painful but learning as well. So you can test it here: http://lionss-codeornot.rhcloud.com/ Because of all the changes and the inital request, I am not sure this is what you expect. Don't mind to provide use cases so I can improve my work. Best, Mat ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: l10n process, en_US version, Help files
Hi Caolán, Le 18/12/2013 11:19, Caolán McNamara a écrit : [...] * 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. Thank you very much for your suggestions. Would your two last suggestions fall also under easyhacks or is it something more complicated to code? Kind regards Sophie ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: l10n process, en_US version, Help files
On Wed, Dec 18, 2013 at 10:07:34AM +, Caolán McNamara wrote: On Thu, 2013-12-12 at 12:40 +0200, Khaled Hosny wrote: If the localizers don’t test the actual UI (which I doubt they do, given how long it takes to build LibreOffice) and just translate the strings in Pootle, they are very unlikely to spot such inconsistencies, no matter how many teams we have. What I hope we can eventually do here is that as we move completely to the .ui format, we can then deploy/integrate something like deckard into the translation process (http://deckard.malizor.org/) so that translators can see an image of the dialog they are translating right in the pootle site. Yes, that would very helpful, though figuring a good UI for that will be “interesting”, but lets not worry about this now :) Regards, Khaled ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: l10n process, en_US version, Help files
On Thu, 2013-12-12 at 12:40 +0200, Khaled Hosny wrote: If the localizers don’t test the actual UI (which I doubt they do, given how long it takes to build LibreOffice) and just translate the strings in Pootle, they are very unlikely to spot such inconsistencies, no matter how many teams we have. What I hope we can eventually do here is that as we move completely to the .ui format, we can then deploy/integrate something like deckard into the translation process (http://deckard.malizor.org/) so that translators can see an image of the dialog they are translating right in the pootle site. C. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
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. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [libreoffice-l10n] Re: l10n process, en_US version, Help files
Hi :) I am fairly sure the Documentation Team is NOT up to doing this but perhaps with a little help they might be? They wont be able to do any of the coding, however easy it is, but the skeleton help-page sounds like something they might be really good at. They recently got into doing the wiki-Faq so they might be less scared of working around coding tags and such nowadays. Would it be a good idea to give them a proposal of what might be required? Regards from Tom :) On 18 December 2013 10:19, Caolán McNamara caol...@redhat.com wrote: 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 ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: l10n process, en_US version, Help files
Hi Mat, Le 12/12/2013 22:56, Mat M a écrit : Hi all My grain of salt there. I strongly believe we need to cross-talk, so I go on cross-posting. Thanks a lot for your input, jumping to my question: [...] * And... fixing ! Easy hacks or l10n sessions to fix that are both valid choices. We may want to automate finding occurrences of text in the code. We began with fdo#39439, but further steps are required. did you submit your work, is it now integrated? Kind regards Sophie ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: l10n process, en_US version, Help files
Hi Sophie Le Fri, 13 Dec 2013 10:01:05 +0100, Sophie gautier.sop...@gmail.com a écrit: Hi Mat, Le 12/12/2013 22:56, Mat M a écrit : Hi all My grain of salt there. I strongly believe we need to cross-talk, so I go on cross-posting. Thanks a lot for your input, jumping to my question: [...] * And... fixing ! Easy hacks or l10n sessions to fix that are both valid choices. We may want to automate finding occurrences of text in the code. We began with fdo#39439, but further steps are required. did you submit your work, is it now integrated? I already sent the first draft to Michael Meeks, but we have to find a server to host it. So submitted but not integrated. Mat M ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: l10n process, en_US version, Help files
On Thu, Dec 12, 2013 at 11:18:59AM +0100, Andras Timar wrote: On 2013.12.11. 17:19, Sophie wrote: - 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. :) If the localizers don’t test the actual UI (which I doubt they do, given how long it takes to build LibreOffice) and just translate the strings in Pootle, they are very unlikely to spot such inconsistencies, no matter how many teams we have. Regards, Khaled ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: l10n process, en_US version, Help files
On Thu, Dec 12, 2013 at 11:40 AM, Khaled Hosny khaledho...@eglug.orgwrote: On Thu, Dec 12, 2013 at 11:18:59AM +0100, Andras Timar wrote: On 2013.12.11. 17:19, Sophie wrote: - 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. :) If the localizers don’t test the actual UI (which I doubt they do, given how long it takes to build LibreOffice) and just translate the strings in Pootle, they are very unlikely to spot such inconsistencies, no matter how many teams we have. Regards, Khaled ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice And frankly, most translators don't bother reporting such errors (or any errors at all). There is enough work with the translation itself and Pootle not having any way to report errors (though that function is already being worked on) doesn't help. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
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 ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: l10n process, en_US version, Help files
Hi all My grain of salt there. I strongly believe we need to cross-talk, so I go on cross-posting. Le Thu, 12 Dec 2013 13:54:05 +0100, Sophie gautier.sop...@gmail.com a écrit: 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 Further discussed - 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) [...] Not sure, as Khaled said, it may be because the load of work on translation is enough to not take care of other things. We have three steps here: - Seeing the typo / obvious inconsistency - Marking the typo - Fixing the typo * See : With a en-US ui, you can catch some during normal work Else, you are in a chase for them (QA, l10n, someone ? ). * Next step is to mark them. When you are in a chase, you can organize stuff to avoid duplicate work and jot all references to, say, a wiki page or an etherpad, whatever fits When you catch one on LO: what will make you go further ? Easiness. We need a simple process to submit. The counterpart is that we may have many false positives, so more filtering to do. Conclusion : either we provide a simple way to report a miss in the text because it may provide useful input, or we consider not having enough people to filter, and we limit ourselves to chases. * And... fixing ! Easy hacks or l10n sessions to fix that are both valid choices. We may want to automate finding occurrences of text in the code. We began with fdo#39439, but further steps are required. * 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. And who is this someone ? BTW, I don't really know the workflow to provide some help content, but I think the developer creating a help button should at list input some draft so people have a start to improve (like we had some lengthy comments on usage in code before). We may have a script to parse the code and find help links without targets, but to fight against obsolescence, we need people involved and scanning the help, or like typos an easy way to report. We are more in a typewriting review process than a l10n one, so maybe we need doc@ here. - 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. If I admit your example is quite useless, Andras, we have many not-at-all savvy users which actually needs the help, and the basic one, not the expert one. That is the hard stuff. I don't want to dive into tutorials in help, but a good explanantion and an example may help people figure how to use something or to determine if this something is what they are searching for. Remember that we have many facilities in LibreOffice, and we don't know them all. So at one point you have to search for them. And here goes the help system. 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 [...] 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 [...] 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. We can have a start saying all contributore to libreoffice are
l10n process, en_US version, Help files
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 ;) - 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. Thanks for reading :) Cheers Sophie ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
