Re: PO files headers and DL
Thanks for the idea, but using a find command may be easier :) Btw, GUI files are always (unless some exceptions) in modulename/po, so I just need use find to know where is the doc folder. 2012/1/3 Simos Xenitellis simos.li...@googlemail.com 2012/1/2 Daniel Mustieles García daniel.mustie...@gmail.com Hi Simos, PO editors should be able to manage headers without eating them, and translators doesn't use to edit PO files manually, btw, if this feature is finally implemented in DL, it should be able to detect and fix malformed headers. Using an online XML file is another posibility, but I don't like it, since it adds too mucho difficult (at least for me) to parse the XML file with bash (I've tried to read and understand your script, but I don't know Python :( ). In this case, a simple «find» command works fine and can solve the problem without parsing XML files. Hi Daniel, You could use 'xml2', http://www.ofb.net/~egnor/xml2/ as a way to convert the XML file into a format suitable for shell scripting. The output of xml2 looks like ... /stats/category/module /stats/category/module/@id=gnome-games /stats/category/module/@branch=master /stats/category/module/document/@id=glines /stats/category/module/document/translated=1 /stats/category/module/document/fuzzy=0 /stats/category/module/document/untranslated=11 /stats/category/module/document/pofile=/POT/gnome-games.master/docs/glines.master.el.po /stats/category/module/document/svnpath= http://git.gnome.org/browse/gnome-games/glines/help /stats/category/module/document /stats/category/module/document/@id=gnect /stats/category/module/document/translated=83 /stats/category/module/document/fuzzy=1 /stats/category/module/document/untranslated=0 /stats/category/module/document/pofile=/POT/gnome-games.master/docs/gnect.master.el.po /stats/category/module/document/svnpath= http://git.gnome.org/browse/gnome-games/gnect/help So, if you want to figure out where to place the gnect documentation, you find the @id=gnect line and then extract the 'svnpath' line which has http://git.gnome.org/browse/gnome-games/gnect/help;. Nevertheless, adding such a dependency might be an issue for your program. In a first look, Chusslove's idea could be fine, not only for this kind of script, but for other ones. Note that, if bash script works properly, and can be used to make several tasks (I've implemented the following features: change all modules to master, branch, change to master, deleting old branches and «git pull» all downloaded modules) this script could be ported to GTK, so you could add more features, like an «author» field for your translations (this feature could help coordinators to upload several po files with different author for each file, default would be the commiter itself). A case scenario that I think it's useful, is to allow to have 'translator work packages'. That is, we get the http://l10n.gnome.org/languages/el/gnome-3-4/ui.tar.gz file with all the PO files (this one for UI), and let a translator make changes across any PO files in the archive. For example, suppose you want to change the translation of 'widget' to a different term; you change lots of PO files. Then, the translator zips back the PO files and sends them for inclusion. The script identifies which PO files have changed, and commits them, all in one go. It can use the filenames to figure out what project/type/branch to use. If it isn't a lot of work, I'd try to implement it, and see what happens. Maybe having it implemented, any translator/developer finds it useful for another purposes. I recommend to post the code online at a service such as github.com, so that other can follow and they might try to help out. Good luck with your work, Simos Many thanks for your comments :) 2011/12/30 Simos Xenitellis simos.li...@googlemail.com 2011/12/29 Daniel Mustieles García daniel.mustie...@gmail.com What about this issue? Is there any possibility to add headers to PO files? It could be possible, at least, to add this header just to es.po files? It woulb be very useful for me and for other translators/coordinators, and it is completely transparent for translations (just note the X-Generator header added by Kbabel or PoEdit). I think it would be problematic to depend on the header of the PO files for the location in the repository. Some translation programs strip headers, some translators may edit the header manually, and so on. I am not sure how you receive the list of GNOME packages that you clone; in my attempt for such a program, https://github.com/simos/gnome-i18n-manage-vcs I parse the XML release information which can be used to deduce the location of the PO files. For example, for the GNOME 3.4 release, the XML file is at http://l10n.gnome.org/languages/el/gnome-3-4/xml If I want to find the location for the mahjongg documentation, I can deduce it from
Re: PO files headers and DL
Den 10-12-2011 20:37, Daniel Mustieles García skrev: Hi all, I've been developing a small bash script to help me with some git tasks, such as updating all my downloaded git clones, deleting all branches and, the most important, commiting automatically PO files from the GUI (not documentation). Well, at this momment, I'm working with the PO filenames to know where I have to copy the PO file (i.e., anjuta.master.es.po must be copied in anjuta/po/es.po). This is relatively easy, since GUI files are always (unless a ver few exceptions) in the module/po folder, but this rule can't be applied with documentation PO files (in the case of Anjuta, PO file is located in anjuta/manuals/anjuta-manual). I've been talking with with Claude about the possibility to add a header (maybe «X-Location»?) to PO files (both GUI and doc ones) containing the folder in which the PO file is located, so I can easily parse it with my script, simplifying it and ensuring I'm copying the PO file in the properly location. This header could be added automatically by DL to PO files, and as a PO file header, should not affect translations nor translators. We wolud like to ask teams coordinators If you agree adding this header to PO files. Note that this header can be used out of the script, for example, if you don't remember where libgda or anjuta's documentations are located. Of course, If anybody wants to take a look into (or use) the script, just tell me and I'll send you a copy of it. I'm using it and works properly (I still have not broken git with it ;-) ) Many thanks to all ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n Provided this can be done with _a small amount_ of work on the damned lies-end I think this is a good idea. About some of the concerns that have been voiced here. I think that it is of course a better solution to make the location uniform, but it is also utopia to think that we can make such a change. With regards to translator programs stripping headers, I inclined to say that they are broken if do so and bug reports should be made. In any case, if the information is there it will help the commiter, if it is not he will have to do it manually. That situation is still better than the way it is now. I welcome the change if it can be implemented without a huge effort. Then I can also make my commit script better (seems like every language coordinator has his own, talk about wasted work). On another subject remember that it is also the plan to at some point make it possible to commit translations directly from damned lies, in which case this problem will become a lot smaller, so that probably makes it even less likely that we should solve it by imposing location rules on a lot of projects. Regards Kenneth ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: PO files headers and DL
[: Daniel Mustieles García :] I've been talking with with Claude about the possibility to add a header (maybe «X-Location»?) to PO files (both GUI and doc ones) containing the folder in which the PO file is located [...] [: Kenneth Nielsen :] [...] On another subject remember that it is also the plan to at some point make it possible to commit translations directly from damned lies, in which case this problem will become a lot smaller, so that probably makes it even less likely that we should solve it by imposing location rules on a lot of projects. This topic is a recurring motif, e.g: http://lists.gnu.org/archive/html/bug-gnu-utils/2008-11/msg00030.html which I argued to go beyond the needs of a particular translation project and therefore deserve full-fledged support from xgettext/msgmerge: http://sourceforge.net/mailarchive/message.php?msg_id=6099532 Failing that, I would make translation-side automatization (Damned Lies in this case) introduce an X-Source-Root custom header field, with some sort of URL to which the source references in the PO file are relative to. Where possible, this would be a web-accessible URL, for example: X-Source-Root: http://git.gnome.org/browse/gnome-games/plain/po\n; This would enable any kind of scripting which needs to connect to the location of the sources while working on an isolated, out-of-tree PO file. This includes automatic committing desired by Daniel, but it does not stop there. For example, a PO editor could use it to show source on demand for a given message, with a single shortcut, reliably and without any preparation. Hence it would be useful regardless of whether translation-side automatization can automatically commit or not; and it would not impose any restrictions on source trees of particular projects. -- Chusslove Illich (Часлав Илић) signature.asc Description: This is a digitally signed message part. ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: PO files headers and DL
Hi Simos, PO editors should be able to manage headers without eating them, and translators doesn't use to edit PO files manually, btw, if this feature is finally implemented in DL, it should be able to detect and fix malformed headers. Using an online XML file is another posibility, but I don't like it, since it adds too mucho difficult (at least for me) to parse the XML file with bash (I've tried to read and understand your script, but I don't know Python :( ). In this case, a simple «find» command works fine and can solve the problem without parsing XML files. In a first look, Chusslove's idea could be fine, not only for this kind of script, but for other ones. Note that, if bash script works properly, and can be used to make several tasks (I've implemented the following features: change all modules to master, branch, change to master, deleting old branches and «git pull» all downloaded modules) this script could be ported to GTK, so you could add more features, like an «author» field for your translations (this feature could help coordinators to upload several po files with different author for each file, default would be the commiter itself). If it isn't a lot of work, I'd try to implement it, and see what happens. Maybe having it implemented, any translator/developer finds it useful for another purposes. Many thanks for your comments :) 2011/12/30 Simos Xenitellis simos.li...@googlemail.com 2011/12/29 Daniel Mustieles García daniel.mustie...@gmail.com What about this issue? Is there any possibility to add headers to PO files? It could be possible, at least, to add this header just to es.po files? It woulb be very useful for me and for other translators/coordinators, and it is completely transparent for translations (just note the X-Generator header added by Kbabel or PoEdit). I think it would be problematic to depend on the header of the PO files for the location in the repository. Some translation programs strip headers, some translators may edit the header manually, and so on. I am not sure how you receive the list of GNOME packages that you clone; in my attempt for such a program, https://github.com/simos/gnome-i18n-manage-vcs I parse the XML release information which can be used to deduce the location of the PO files. For example, for the GNOME 3.4 release, the XML file is at http://l10n.gnome.org/languages/el/gnome-3-4/xml If I want to find the location for the mahjongg documentation, I can deduce it from http://l10n.gnome.org/languages/el/gnome-3-4/xml and the line svnpathhttp://git.gnome.org/browse/gnome-games/mahjongg/help/svnpath In this example, el.po would be located in gnome-games/mahjongg/help/LL/LL.po (LL: language) because the type of repository is 'help' (also defined in the XML file). The current status of https://github.com/simos/gnome-i18n-manage-vcs is that you can manage your repositories, such as updating them all (git pull --rebase). You can also press a key to interrupt the update. There is code to make commits, however it needs a bit more work. Feel free to work on the repository; I'ld be happy to help out, etc. Happy New Year to all GNOME I18n, Simos El 13 de diciembre de 2011 16:45, Daniel Mustieles García daniel.mustie...@gmail.com escribió: Headers can be split in two (or more) lines? I this case, how could a bash script get the full path? Thanks for your comment :) 2011/12/13 F Wolff frie...@translate.org.za Op So, 2011-12-11 om 10:57 +0100 skryf Daniel Mustieles García: I agree with Matei: the bes solution would be if GUI files were always in PO filder, and documentation files were in HELP folder, but there are some incoveniences for it. First of all, there isn't a written rule saying where PO files mus be. Each developer chooses their location, and especifies it in makefile or configure.in files, so It will be difficult to change all modules. In the other hand, there are several modules with special cases: gtk has po and po-properties folders; gimp-help has several folders with po files with different names (appendix.po, render.po, etc). Also, note that rules about po files in forlder can change (today, help folder is a good idea to keep documentation, but tomowwor it may change), but PO files are not expected to change their format. Having an X-Location header in a po file, allows me doing a loop like this: for file in $translations_to_commit do PO_LOCATION=`grep X-Location $i ...` #Here I could use sed to get a clean path cp $file $PO_LOCATION done This is a very simple and safe loop (there is no possibility to copy a po file in a wrong location). This sounds like an interesting idea. We need to realise that tools can wrap the lines in the path, and that a simple grep might not work correctly. Something like this is possible: msgstr ... X-Location: gnome-control-center/ help/\n So the script might need a bit more
Re: PO files headers and DL
2012/1/2 Daniel Mustieles García daniel.mustie...@gmail.com Hi Simos, PO editors should be able to manage headers without eating them, and translators doesn't use to edit PO files manually, btw, if this feature is finally implemented in DL, it should be able to detect and fix malformed headers. Using an online XML file is another posibility, but I don't like it, since it adds too mucho difficult (at least for me) to parse the XML file with bash (I've tried to read and understand your script, but I don't know Python :( ). In this case, a simple «find» command works fine and can solve the problem without parsing XML files. Hi Daniel, You could use 'xml2', http://www.ofb.net/~egnor/xml2/ as a way to convert the XML file into a format suitable for shell scripting. The output of xml2 looks like ... /stats/category/module /stats/category/module/@id=gnome-games /stats/category/module/@branch=master /stats/category/module/document/@id=glines /stats/category/module/document/translated=1 /stats/category/module/document/fuzzy=0 /stats/category/module/document/untranslated=11 /stats/category/module/document/pofile=/POT/gnome-games.master/docs/glines.master.el.po /stats/category/module/document/svnpath= http://git.gnome.org/browse/gnome-games/glines/help /stats/category/module/document /stats/category/module/document/@id=gnect /stats/category/module/document/translated=83 /stats/category/module/document/fuzzy=1 /stats/category/module/document/untranslated=0 /stats/category/module/document/pofile=/POT/gnome-games.master/docs/gnect.master.el.po /stats/category/module/document/svnpath= http://git.gnome.org/browse/gnome-games/gnect/help So, if you want to figure out where to place the gnect documentation, you find the @id=gnect line and then extract the 'svnpath' line which has http://git.gnome.org/browse/gnome-games/gnect/help;. Nevertheless, adding such a dependency might be an issue for your program. In a first look, Chusslove's idea could be fine, not only for this kind of script, but for other ones. Note that, if bash script works properly, and can be used to make several tasks (I've implemented the following features: change all modules to master, branch, change to master, deleting old branches and «git pull» all downloaded modules) this script could be ported to GTK, so you could add more features, like an «author» field for your translations (this feature could help coordinators to upload several po files with different author for each file, default would be the commiter itself). A case scenario that I think it's useful, is to allow to have 'translator work packages'. That is, we get the http://l10n.gnome.org/languages/el/gnome-3-4/ui.tar.gz file with all the PO files (this one for UI), and let a translator make changes across any PO files in the archive. For example, suppose you want to change the translation of 'widget' to a different term; you change lots of PO files. Then, the translator zips back the PO files and sends them for inclusion. The script identifies which PO files have changed, and commits them, all in one go. It can use the filenames to figure out what project/type/branch to use. If it isn't a lot of work, I'd try to implement it, and see what happens. Maybe having it implemented, any translator/developer finds it useful for another purposes. I recommend to post the code online at a service such as github.com, so that other can follow and they might try to help out. Good luck with your work, Simos Many thanks for your comments :) 2011/12/30 Simos Xenitellis simos.li...@googlemail.com 2011/12/29 Daniel Mustieles García daniel.mustie...@gmail.com What about this issue? Is there any possibility to add headers to PO files? It could be possible, at least, to add this header just to es.po files? It woulb be very useful for me and for other translators/coordinators, and it is completely transparent for translations (just note the X-Generator header added by Kbabel or PoEdit). I think it would be problematic to depend on the header of the PO files for the location in the repository. Some translation programs strip headers, some translators may edit the header manually, and so on. I am not sure how you receive the list of GNOME packages that you clone; in my attempt for such a program, https://github.com/simos/gnome-i18n-manage-vcs I parse the XML release information which can be used to deduce the location of the PO files. For example, for the GNOME 3.4 release, the XML file is at http://l10n.gnome.org/languages/el/gnome-3-4/xml If I want to find the location for the mahjongg documentation, I can deduce it from http://l10n.gnome.org/languages/el/gnome-3-4/xml and the line svnpathhttp://git.gnome.org/browse/gnome-games/mahjongg/help /svnpath In this example, el.po would be located in gnome-games/mahjongg/help/LL/LL.po (LL: language) because the type of repository is 'help' (also defined in the XML file). The current
Re: PO files headers and DL
2011/12/29 Daniel Mustieles García daniel.mustie...@gmail.com What about this issue? Is there any possibility to add headers to PO files? It could be possible, at least, to add this header just to es.po files? It woulb be very useful for me and for other translators/coordinators, and it is completely transparent for translations (just note the X-Generator header added by Kbabel or PoEdit). I think it would be problematic to depend on the header of the PO files for the location in the repository. Some translation programs strip headers, some translators may edit the header manually, and so on. I am not sure how you receive the list of GNOME packages that you clone; in my attempt for such a program, https://github.com/simos/gnome-i18n-manage-vcs I parse the XML release information which can be used to deduce the location of the PO files. For example, for the GNOME 3.4 release, the XML file is at http://l10n.gnome.org/languages/el/gnome-3-4/xml If I want to find the location for the mahjongg documentation, I can deduce it from http://l10n.gnome.org/languages/el/gnome-3-4/xml and the line svnpathhttp://git.gnome.org/browse/gnome-games/mahjongg/help/svnpath In this example, el.po would be located in gnome-games/mahjongg/help/LL/LL.po (LL: language) because the type of repository is 'help' (also defined in the XML file). The current status of https://github.com/simos/gnome-i18n-manage-vcs is that you can manage your repositories, such as updating them all (git pull --rebase). You can also press a key to interrupt the update. There is code to make commits, however it needs a bit more work. Feel free to work on the repository; I'ld be happy to help out, etc. Happy New Year to all GNOME I18n, Simos El 13 de diciembre de 2011 16:45, Daniel Mustieles García daniel.mustie...@gmail.com escribió: Headers can be split in two (or more) lines? I this case, how could a bash script get the full path? Thanks for your comment :) 2011/12/13 F Wolff frie...@translate.org.za Op So, 2011-12-11 om 10:57 +0100 skryf Daniel Mustieles García: I agree with Matei: the bes solution would be if GUI files were always in PO filder, and documentation files were in HELP folder, but there are some incoveniences for it. First of all, there isn't a written rule saying where PO files mus be. Each developer chooses their location, and especifies it in makefile or configure.in files, so It will be difficult to change all modules. In the other hand, there are several modules with special cases: gtk has po and po-properties folders; gimp-help has several folders with po files with different names (appendix.po, render.po, etc). Also, note that rules about po files in forlder can change (today, help folder is a good idea to keep documentation, but tomowwor it may change), but PO files are not expected to change their format. Having an X-Location header in a po file, allows me doing a loop like this: for file in $translations_to_commit do PO_LOCATION=`grep X-Location $i ...` #Here I could use sed to get a clean path cp $file $PO_LOCATION done This is a very simple and safe loop (there is no possibility to copy a po file in a wrong location). This sounds like an interesting idea. We need to realise that tools can wrap the lines in the path, and that a simple grep might not work correctly. Something like this is possible: msgstr ... X-Location: gnome-control-center/ help/\n So the script might need a bit more intelligence than simple grep. Keep up the good work! Friedel -- Recently on my blog: http://translate.org.za/blogs/friedel/en/content/firefox-maybe-now-most-popular-africa ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n -- A. Because it breaks the logical sequence of discussion Q. Why is top posting bad? ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: PO files headers and DL
What about this issue? Is there any possibility to add headers to PO files? It could be possible, at least, to add this header just to es.po files? It woulb be very useful for me and for other translators/coordinators, and it is completely transparent for translations (just note the X-Generator header added by Kbabel or PoEdit). Many thanks and Merry X-Mas El 13 de diciembre de 2011 16:45, Daniel Mustieles García daniel.mustie...@gmail.com escribió: Headers can be split in two (or more) lines? I this case, how could a bash script get the full path? Thanks for your comment :) 2011/12/13 F Wolff frie...@translate.org.za Op So, 2011-12-11 om 10:57 +0100 skryf Daniel Mustieles García: I agree with Matei: the bes solution would be if GUI files were always in PO filder, and documentation files were in HELP folder, but there are some incoveniences for it. First of all, there isn't a written rule saying where PO files mus be. Each developer chooses their location, and especifies it in makefile or configure.in files, so It will be difficult to change all modules. In the other hand, there are several modules with special cases: gtk has po and po-properties folders; gimp-help has several folders with po files with different names (appendix.po, render.po, etc). Also, note that rules about po files in forlder can change (today, help folder is a good idea to keep documentation, but tomowwor it may change), but PO files are not expected to change their format. Having an X-Location header in a po file, allows me doing a loop like this: for file in $translations_to_commit do PO_LOCATION=`grep X-Location $i ...` #Here I could use sed to get a clean path cp $file $PO_LOCATION done This is a very simple and safe loop (there is no possibility to copy a po file in a wrong location). This sounds like an interesting idea. We need to realise that tools can wrap the lines in the path, and that a simple grep might not work correctly. Something like this is possible: msgstr ... X-Location: gnome-control-center/ help/\n So the script might need a bit more intelligence than simple grep. Keep up the good work! Friedel -- Recently on my blog: http://translate.org.za/blogs/friedel/en/content/firefox-maybe-now-most-popular-africa ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: PO files headers and DL
Op So, 2011-12-11 om 10:57 +0100 skryf Daniel Mustieles García: I agree with Matei: the bes solution would be if GUI files were always in PO filder, and documentation files were in HELP folder, but there are some incoveniences for it. First of all, there isn't a written rule saying where PO files mus be. Each developer chooses their location, and especifies it in makefile or configure.in files, so It will be difficult to change all modules. In the other hand, there are several modules with special cases: gtk has po and po-properties folders; gimp-help has several folders with po files with different names (appendix.po, render.po, etc). Also, note that rules about po files in forlder can change (today, help folder is a good idea to keep documentation, but tomowwor it may change), but PO files are not expected to change their format. Having an X-Location header in a po file, allows me doing a loop like this: for file in $translations_to_commit do PO_LOCATION=`grep X-Location $i ...` #Here I could use sed to get a clean path cp $file $PO_LOCATION done This is a very simple and safe loop (there is no possibility to copy a po file in a wrong location). This sounds like an interesting idea. We need to realise that tools can wrap the lines in the path, and that a simple grep might not work correctly. Something like this is possible: msgstr ... X-Location: gnome-control-center/ help/\n So the script might need a bit more intelligence than simple grep. Keep up the good work! Friedel -- Recently on my blog: http://translate.org.za/blogs/friedel/en/content/firefox-maybe-now-most-popular-africa ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: PO files headers and DL
Headers can be split in two (or more) lines? I this case, how could a bash script get the full path? Thanks for your comment :) 2011/12/13 F Wolff frie...@translate.org.za Op So, 2011-12-11 om 10:57 +0100 skryf Daniel Mustieles García: I agree with Matei: the bes solution would be if GUI files were always in PO filder, and documentation files were in HELP folder, but there are some incoveniences for it. First of all, there isn't a written rule saying where PO files mus be. Each developer chooses their location, and especifies it in makefile or configure.in files, so It will be difficult to change all modules. In the other hand, there are several modules with special cases: gtk has po and po-properties folders; gimp-help has several folders with po files with different names (appendix.po, render.po, etc). Also, note that rules about po files in forlder can change (today, help folder is a good idea to keep documentation, but tomowwor it may change), but PO files are not expected to change their format. Having an X-Location header in a po file, allows me doing a loop like this: for file in $translations_to_commit do PO_LOCATION=`grep X-Location $i ...` #Here I could use sed to get a clean path cp $file $PO_LOCATION done This is a very simple and safe loop (there is no possibility to copy a po file in a wrong location). This sounds like an interesting idea. We need to realise that tools can wrap the lines in the path, and that a simple grep might not work correctly. Something like this is possible: msgstr ... X-Location: gnome-control-center/ help/\n So the script might need a bit more intelligence than simple grep. Keep up the good work! Friedel -- Recently on my blog: http://translate.org.za/blogs/friedel/en/content/firefox-maybe-now-most-popular-africa ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: PO files headers and DL
2011/12/12 Matej Urban matej.ur...@gmail.com Well, looking at other projects there are at least three logical solutions that some project use and do not complicate the system. - first is creating different po-folders for extra translations, like /po, /po-lalala, /po-help with xx.po files - second is keeping the current path of /po, but renaming the files like xx.po, xx.properties.po, xx.help.po ... - third is creating language folder (twoletter code) like /po/xx/files like properties.po, ui.po, help.po whatever.po The path should be guessable. I case of locator I already feel, there will be problems, because the commiter is not in control. The problem is that DL renames po files, and I have to analyze and «change» them to know where I have to copy the file. Changing folders names or its structure doesn't solve the problem. This script is very useful when you have to commit a lot of files you've translated, so you are the commiter. If there are several translators, but just one commiter, script doesn't works, but my idea is, if this script is useful for many translation temas/corrdinators, port it to GTK, adding some features, and this could be a great one. I still think that changing all modules structure is being near impossible... I like Jorge's idea, since it wolud be easy to parse, and it may be easy to maintain M! 2011/12/11 Daniel Mustieles García daniel.mustie...@gmail.com I agree with Matei: the bes solution would be if GUI files were always in PO filder, and documentation files were in HELP folder, but there are some incoveniences for it. First of all, there isn't a written rule saying where PO files mus be. Each developer chooses their location, and especifies it in makefile or configure.in files, so It will be difficult to change all modules. In the other hand, there are several modules with special cases: gtk has po and po-properties folders; gimp-help has several folders with po files with different names (appendix.po, render.po, etc). Also, note that rules about po files in forlder can change (today, help folder is a good idea to keep documentation, but tomowwor it may change), but PO files are not expected to change their format. Having an X-Location header in a po file, allows me doing a loop like this: for file in $translations_to_commit do PO_LOCATION=`grep X-Location $i ...` #Here I could use sed to get a clean path cp $file $PO_LOCATION done This is a very simple and safe loop (there is no possibility to copy a po file in a wrong location). Since changing all existing modules is a hard task, I vote for my idea to help translators to commit files into git. I think that, on today, this is the best and less painful solution to automate some translator tasks. Cheers! ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: PO files headers and DL
I agree with Matei: the bes solution would be if GUI files were always in PO filder, and documentation files were in HELP folder, but there are some incoveniences for it. First of all, there isn't a written rule saying where PO files mus be. Each developer chooses their location, and especifies it in makefile or configure.in files, so It will be difficult to change all modules. In the other hand, there are several modules with special cases: gtk has po and po-properties folders; gimp-help has several folders with po files with different names (appendix.po, render.po, etc). Also, note that rules about po files in forlder can change (today, help folder is a good idea to keep documentation, but tomowwor it may change), but PO files are not expected to change their format. Having an X-Location header in a po file, allows me doing a loop like this: for file in $translations_to_commit do PO_LOCATION=`grep X-Location $i ...` #Here I could use sed to get a clean path cp $file $PO_LOCATION done This is a very simple and safe loop (there is no possibility to copy a po file in a wrong location). Since changing all existing modules is a hard task, I vote for my idea to help translators to commit files into git. I think that, on today, this is the best and less painful solution to automate some translator tasks. Cheers! 2011/12/10 Chris Leonard cjlhomeaddr...@gmail.com 2011/12/10 Daniel Mustieles García daniel.mustie...@gmail.com: Hi all, I've been developing a small bash script to help me with some git tasks, such as updating all my downloaded git clones, deleting all branches and, the most important, commiting automatically PO files from the GUI (not documentation). Well, at this momment, I'm working with the PO filenames to know where I have to copy the PO file (i.e., anjuta.master.es.po must be copied in anjuta/po/es.po). This is relatively easy, since GUI files are always (unless a ver few exceptions) in the module/po folder, but this rule can't be applied with documentation PO files (in the case of Anjuta, PO file is located in anjuta/manuals/anjuta-manual). I've been talking with with Claude about the possibility to add a header (maybe «X-Location»?) to PO files (both GUI and doc ones) containing the folder in which the PO file is located, so I can easily parse it with my script, simplifying it and ensuring I'm copying the PO file in the properly location. This header could be added automatically by DL to PO files, and as a PO file header, should not affect translations nor translators. We wolud like to ask teams coordinators If you agree adding this header to PO files. Note that this header can be used out of the script, for example, if you don't remember where libgda or anjuta's documentations are located. Of course, If anybody wants to take a look into (or use) the script, just tell me and I'll send you a copy of it. I'm using it and works properly (I still have not broken git with it ;-) ) Many thanks to all I am sympathetic to the sentiments expressed by Matej Urban in his restrained rant that the real answer is to ask developers to work towards uniformity wherever it is possible. At Sugar Labs, we face similar challenges when generating language packs that are self-installing scripts that contain the latest MO files (updated and overwritten nightly), so the notion of imposing the burden on the developer to explicitly specify within the PO file any necessary information about non-standard locations (either in the repo for PO files in your example or on the local filesystem for MO files in my language pack example) is interesting. I guess my obvious concern is what makes you think that these developers would be any better about documenting their non-standard practices than they are about following generally accepted practices about how to structure their repos? cjl Sugar Labs Translation Team Coordinator http://translate.sugarlabs.org/ ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: PO files headers and DL
Well, looking at other projects there are at least three logical solutions that some project use and do not complicate the system. - first is creating different po-folders for extra translations, like /po, /po-lalala, /po-help with xx.po files - second is keeping the current path of /po, but renaming the files like xx.po, xx.properties.po, xx.help.po ... - third is creating language folder (twoletter code) like /po/xx/files like properties.po, ui.po, help.po whatever.po The path should be guessable. I case of locator I already feel, there will be problems, because the commiter is not in control. M! 2011/12/11 Daniel Mustieles García daniel.mustie...@gmail.com I agree with Matei: the bes solution would be if GUI files were always in PO filder, and documentation files were in HELP folder, but there are some incoveniences for it. First of all, there isn't a written rule saying where PO files mus be. Each developer chooses their location, and especifies it in makefile or configure.in files, so It will be difficult to change all modules. In the other hand, there are several modules with special cases: gtk has po and po-properties folders; gimp-help has several folders with po files with different names (appendix.po, render.po, etc). Also, note that rules about po files in forlder can change (today, help folder is a good idea to keep documentation, but tomowwor it may change), but PO files are not expected to change their format. Having an X-Location header in a po file, allows me doing a loop like this: for file in $translations_to_commit do PO_LOCATION=`grep X-Location $i ...` #Here I could use sed to get a clean path cp $file $PO_LOCATION done This is a very simple and safe loop (there is no possibility to copy a po file in a wrong location). Since changing all existing modules is a hard task, I vote for my idea to help translators to commit files into git. I think that, on today, this is the best and less painful solution to automate some translator tasks. Cheers! ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: PO files headers and DL
Hello, I complained about this some time ago, but I can not find the thread. :) I too wrote myself a basic script to do exactly what you described, but shortly I found that was not enough. I had to change if frequently until I ended up with the script that worked for UI translations that keep translations in package/po/ and help files in package/help/. Since many, many project like to use different paths (why?) like doc, docs, lalala, I had do add those. Then I had to add translators to credit their work ... I ended with the script based on the file name (packagename.type.branch.translator.language.po) that worked great until I stumbled upon projects that have some bizarre paths (why?) ... and yes, I had to add a locator to those po files header. I used firstline #' path/path since it was the only way I figured how to parse the filecontents in bash (I'm not really a bash programmer but it seems I managed so far). To end and follow this rant, I think adding locator seems wrong until projects have no defined structure. I think in the first place all project should use /po for UI and /help for help ... there is no need for more complications. In case a Locator is added, I'd ask a bash guru to also include some info about getting the path out of the file. M! 2011/12/10 Daniel Mustieles García daniel.mustie...@gmail.com Hi all, I've been developing a small bash script to help me with some git tasks, such as updating all my downloaded git clones, deleting all branches and, the most important, commiting automatically PO files from the GUI (not documentation). Well, at this momment, I'm working with the PO filenames to know where I have to copy the PO file (i.e., anjuta.master.es.po must be copied in anjuta/po/es.po). This is relatively easy, since GUI files are always (unless a ver few exceptions) in the module/po folder, but this rule can't be applied with documentation PO files (in the case of Anjuta, PO file is located in anjuta/manuals/anjuta-manual). I've been talking with with Claude about the possibility to add a header (maybe «X-Location»?) to PO files (both GUI and doc ones) containing the folder in which the PO file is located, so I can easily parse it with my script, simplifying it and ensuring I'm copying the PO file in the properly location. This header could be added automatically by DL to PO files, and as a PO file header, should not affect translations nor translators. We wolud like to ask teams coordinators If you agree adding this header to PO files. Note that this header can be used out of the script, for example, if you don't remember where libgda or anjuta's documentations are located. Of course, If anybody wants to take a look into (or use) the script, just tell me and I'll send you a copy of it. I'm using it and works properly (I still have not broken git with it ;-) ) Many thanks to all ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: PO files headers and DL
2011/12/10 Daniel Mustieles García daniel.mustie...@gmail.com: Hi all, I've been developing a small bash script to help me with some git tasks, such as updating all my downloaded git clones, deleting all branches and, the most important, commiting automatically PO files from the GUI (not documentation). Well, at this momment, I'm working with the PO filenames to know where I have to copy the PO file (i.e., anjuta.master.es.po must be copied in anjuta/po/es.po). This is relatively easy, since GUI files are always (unless a ver few exceptions) in the module/po folder, but this rule can't be applied with documentation PO files (in the case of Anjuta, PO file is located in anjuta/manuals/anjuta-manual). I've been talking with with Claude about the possibility to add a header (maybe «X-Location»?) to PO files (both GUI and doc ones) containing the folder in which the PO file is located, so I can easily parse it with my script, simplifying it and ensuring I'm copying the PO file in the properly location. This header could be added automatically by DL to PO files, and as a PO file header, should not affect translations nor translators. We wolud like to ask teams coordinators If you agree adding this header to PO files. Note that this header can be used out of the script, for example, if you don't remember where libgda or anjuta's documentations are located. Of course, If anybody wants to take a look into (or use) the script, just tell me and I'll send you a copy of it. I'm using it and works properly (I still have not broken git with it ;-) ) Many thanks to all I am sympathetic to the sentiments expressed by Matej Urban in his restrained rant that the real answer is to ask developers to work towards uniformity wherever it is possible. At Sugar Labs, we face similar challenges when generating language packs that are self-installing scripts that contain the latest MO files (updated and overwritten nightly), so the notion of imposing the burden on the developer to explicitly specify within the PO file any necessary information about non-standard locations (either in the repo for PO files in your example or on the local filesystem for MO files in my language pack example) is interesting. I guess my obvious concern is what makes you think that these developers would be any better about documenting their non-standard practices than they are about following generally accepted practices about how to structure their repos? cjl Sugar Labs Translation Team Coordinator http://translate.sugarlabs.org/ ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
