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
