Re: PO files headers and DL

[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/