Re: [Gretl-devel] translating gretl docs
On Sun, 1 Jan 2017, Riccardo (Jack) Lucchetti wrote:
On Sat, 31 Dec 2016, Allin Cottrell wrote:
> I've put a sample pot file (for the function reference) at
> http://users.wfu.edu/cottrell/tmp/gretl_functions.pot . Comments invited.
The main advantage would be giving translators a tool for monitoring possible
inconsistencies between versions, spotting new entries, etc. I've put
together, over the years, a few in-house tools to deal with this but I'm not
at all adverse to changing my habits. From looking at the potfile you've
created, however, a few things leave me a little perplexed.
The gettext system is designed to deal with short segments of text, possibly
repeated many times. You translate each segment once, and the work is done
(also nice for consistency). However, this may not be desirable when longer,
more articulate texts have to be translated, as sometimes there is no
one-to-one correspondence between languages. An example from the two
languages I know best
ENG ITA
------------------------
Free Libero
Free Gratis
Nephew Nipote
Grandson Nipote
------------------------
Of course, what matters here is the context. But then, you miss the most
important advantage of gettext, which is "recycling" many times over the work
you've done once.
And in fact, what you get in the functions potfile is either longish text
fragments that occur once (and the "translate once" advantage of gettext
becomes moot), or infinitesimal tokens like "s", that occur many times, but
possibly in very different contexts, so they may require different
translations in different languages.
But as I said, I'm open to the new system if in fact it's provably more
robust and more efficient than doing things by hand.
Your comments on the use of .po files to translate the gretl help
files seem on the mark to me. The gettext mechanism provides a fairly
easy and systematic way of syncing material, but in other respects
it's far from ideal for the job in hand. (I don't know what would be
ideal.)
I agree that with the po approach the translator is in danger of
losing track of context. Here's one specific example. The names of
function arguments are translatable: this is hardly necessary for
names such as "x" and "y" but can be useful for the likes of
"varlist". OK, but now we need to refer to these arguments by name
(using the <argname> tag) in the body of the function doc -- and given
the way the text gets sliced and diced by gettext, it may not be clear
which names should be used where. I guess that when editing the po
file one would have to have the XML file (or maybe the PDF) open in
another window.
Another issue is transition: Given a translation (full or partial)
that's already in the form of a parallel XML file, how to convert it
to .po? I may be missing something but I don't see an easy way to do
that. One could run xml2po on the translated XML, but the msgid line
numbers wouldn't agree with the English .pot file.
Anyway, I've added in git (under doc/commands):
gretl_functions.pot
gretldoc.py
The py file is a draft xml2po module; to get it used by xml2po I think
it has to go somewhere such as
/usr/lib/python2.7/site-packages/xml2po/modes
So if anyone wishes to try the po approach, please go ahead. But right
now I'm considering it experimental, and I'm certainly not proposing
that this method be required.
To try it out, one would copy gretl_functions.pot to
gretl_functions_LANG.po
and start translating. Then upload the .po to the doc/commands
directory. And then I can use that to generate translated XML -- but
I'll be careful not to overwrite already-translated XML! (Unless and
until anyone definitely decides to go over to the gettext method.)
Allin