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 lists googlemail com>

2011/12/29 Daniel Mustieles García <daniel mustieles 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 mustieles 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 <friedel 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?



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]