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 >> "<svnpath>http://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? >> > > -- 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
