Re: PO files headers and DL

[Daniel Mustieles García <daniel mustieles 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!

2011/12/10 Chris Leonard <cjlhomeaddress gmail com>

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