3:27 p.m.
I've been working lately on making the production of the PDF Command
(and function) Reference from the XML source files more robust. This
leads me to a couple of observations and a question.
First, translating the User's Guide is by now a massive task --
equivalent to translating a big book. But translating the two
reference XML files (gretl_commands_en.xml and
gretl_functions_en.xml) is relatively manageable, and doing so
basically gets you the PDF Reference "for free". There's a certain
amount of supplementary text in a few TeX files, namely cmdref.tex,
funcref.tex, operators.tex, comments.tex, optarg.tex and
reftables.tex (about 20 kbytes total); if these are translated too
then the whole Reference is internationalized.
I see that the front page of the Italian Reference has a note saying
that the translation is frozen as of gretl 1.7.1 but actually that's
not true: since the Italian XML files are up to date, so (basically)
is the Reference. So maybe we could remove that note?
Now for the question. The big problem with translation of the XML
files is ensuring that the translations stay up to date. I'm
wondering if xml2po might be helpful here. I think Alexander
Gedranovich raised this question a while back. I didn't look into it
at the time but now I've done so. Xml2po offers the facility of
stripping the translatable material out of an XML file and making a
pot file (essentially each paragraph becomes a "msgid"), and it also
gives a means of merging translations in a po file back into XML. So
we could use the usual "gettext" procedure, meaning that any updates
to the English versions would be immediately apparent to translators
-- and any newly added material would appear in the translated
versions in English (until it gets translated).
I've put a sample pot file (for the function reference) at
http://users.wfu.edu/cottrell/tmp/gretl_functions.pot . Comments
invited.
Allin
8:34 p.m.
Em 31 de dezembro de 2016, Allin escreveu:
I've been working lately on making the production of the PDF
Command (and
function) Reference from the XML source files more robust. This leads me to
a couple of observations and a question.
First, translating the User's Guide is by now a massive task -- equivalent
to translating a big book. But translating the two reference XML files
(gretl_commands_en.xml and gretl_functions_en.xml) is relatively manageable,
and doing so basically gets you the PDF Reference "for free". There's a
certain amount of supplementary text in a few TeX files, namely cmdref.tex,
funcref.tex, operators.tex, comments.tex, optarg.tex and reftables.tex
(about 20 kbytes total); if these are translated too then the whole
Reference is internationalized.
I see that the front page of the Italian Reference has a note saying that
the translation is frozen as of gretl 1.7.1 but actually that's not true:
since the Italian XML files are up to date, so (basically) is the Reference.
So maybe we could remove that note?
Now for the question. The big problem with translation of the XML files is
ensuring that the translations stay up to date. I'm wondering if xml2po
might be helpful here. I think Alexander Gedranovich raised this question a
while back.
I think it was Ivan Sopov back in 2009 ;-)
http://lists.wfu.edu/pipermail/gretl-devel/2009-December/002302.html
I didn't look into it at the time but now I've done so.
Xml2po
offers the facility of stripping the translatable material out of an XML
file and making a pot file (essentially each paragraph becomes a "msgid"),
and it also gives a means of merging translations in a po file back into
XML. So we could use the usual "gettext" procedure, meaning that any updates
to the English versions would be immediately apparent to translators -- and
any newly added material would appear in the translated versions in English
(until it gets translated).
I've put a sample pot file (for the function reference) at
http://users.wfu.edu/cottrell/tmp/gretl_functions.pot . Comments invited.
This will help me a lot. Now I'm struggling to keep the Portuguese xml
files synced with the English xml. Using po files solves that for me.
Thanks Allin for implementing this and Ivan for suggesting this.
By the way… Happy New Year for all you guys at Gretl Community!
Henrique Andrade
9:29 a.m.
On Sat, 31 Dec 2016, Allin Cottrell wrote:
I see that the front page of the Italian Reference has a note saying
that the
translation is frozen as of gretl 1.7.1 but actually that's not true: since
the Italian XML files are up to date, so (basically) is the Reference. So
maybe we could remove that note?
Yes, absolutely.
Now for the question. The big problem with translation of the XML
files is
ensuring that the translations stay up to date. I'm wondering if xml2po might
be helpful here. I think Alexander Gedranovich raised this question a while
back. I didn't look into it at the time but now I've done so. Xml2po offers
the facility of stripping the translatable material out of an XML file and
making a pot file (essentially each paragraph becomes a "msgid"), and it also
gives a means of merging translations in a po file back into XML. So we could
use the usual "gettext" procedure, meaning that any updates to the English
versions would be immediately apparent to translators -- and any newly added
material would appear in the translated versions in English (until it gets
translated).
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.
-------------------------------------------------------
Riccardo (Jack) Lucchetti
Dipartimento di Scienze Economiche e Sociali (DiSES)
Università Politecnica delle Marche
(formerly known as Università di Ancona)
r.lucchetti(a)univpm.it
http://www2.econ.univpm.it/servizi/hpp/lucchetti
-------------------------------------------------------
6:47 p.m.
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
2901
days inactive
2904
days old
3 comments
3 participants
participants (3)
-
Allin Cottrell -
Henrique Andrade -
Riccardo (Jack) Lucchetti