5:28 p.m.
Hassle, hassle! Sorry, but many of the translations of pages on the
gretl website at sourceforge lag the English versions by months
or years.
Some of the updates to the English pages are fairly trivial, but
some are quite substantive (e.g. revision of the pages relating to
gretl on OS X). Which raises the question of whether non-native
English speakers are better off looking at an up-to-date page in
English or an out-of-date page in their own language.
I'd be very glad to receive suggestions on the best way of keeping
the translations reasonably up to date.
As you know, the gretl web pages are in CVS. It's possible to set up
a notification email when certain parts of CVS change, but I think
that may be non-trivial to get right. I guess I could set up a sort
of website bulletin, such that every so often (say, every 3 months)
I send out an email noting pages that have changed "significantly".
But, given the number of other things I have to do, I'd prefer if
someone can suggest something else!
Allin Cottrell
6:33 p.m.
On Mon, 17 Dec 2012, Allin Cottrell wrote:
I'd be very glad to receive suggestions on the best way of
keeping
the translations reasonably up to date.
After thinking about it, here's one proposal. All the specific
timings below are notional and subject to debate.
1) I designate a subset of the gretl web pages in CVS as "core"
pages and publish this list.
2) I set up a cron (automated batch) job to scan the translations of
the core pages each week. If a translation is found to be more than
three months behind the English version then an automatic email is
sent to its author, saying that if the translation is not updated
within a week it will be replaced by the English version.
3) The cron job detects if a page was flagged, as decribed above,
the previous week and has not been updated. If so, it uploads the
English page to sourceforge in place of the translation. (For
example, if the language in question is "xx", it overwrites the
translation, gretl_foo_xx.html, with the English version,
gretl_foo.html.) It could also send out a second email saying that
this has happened.
4) The cron job keeps a list of any pages that have been replaced in
this way, and if an updated version lands in CVS the translated page
is restored on sourceforge.
Allin
7:23 p.m.
Dear Allin,
I like your proposal. Additionally, I would like to make some
suggestions:
1. It would be nice if Gretl home page automatically recognizes
the country from where the site is accessed (like google.com
does);
2. Instead of http://gretl.sourceforge.net/gretl_portugues.html, we
could use a shorter URL like gretl.sourceforge.net/br (or pt, or es,
etc.) or even gretl.com/br.
What do you think?
Best regards,
Henrique Andrade
Enviado via iPad
Em 17/12/2012, às 21:33, Allin Cottrell <cottrell(a)wfu.edu> escreveu:
On Mon, 17 Dec 2012, Allin Cottrell wrote:
I'd be very glad to receive suggestions on the best way of keeping
the translations reasonably up to date.
After thinking about it, here's one proposal. All the specific
timings below are notional and subject to debate.
1) I designate a subset of the gretl web pages in CVS as "core"
pages and publish this list.
2) I set up a cron (automated batch) job to scan the translations of
the core pages each week. If a translation is found to be more than
three months behind the English version then an automatic email is
sent to its author, saying that if the translation is not updated
within a week it will be replaced by the English version.
3) The cron job detects if a page was flagged, as decribed above,
the previous week and has not been updated. If so, it uploads the
English page to sourceforge in place of the translation. (For
example, if the language in question is "xx", it overwrites the
translation, gretl_foo_xx.html, with the English version,
gretl_foo.html.) It could also send out a second email saying that
this has happened.
4) The cron job keeps a list of any pages that have been replaced in
this way, and if an updated version lands in CVS the translated page
is restored on sourceforge.
Allin
_______________________________________________
Gretl-devel mailing list
Gretl-devel(a)lists.wfu.edu
http://lists.wfu.edu/mailman/listinfo/gretl-devel
9:35 p.m.
On Mon, 17 Dec 2012, Henrique Andrade wrote:
Dear Allin,
I like your proposal. Additionally, I would like to make some
suggestions:
1. It would be nice if Gretl home page automatically recognizes
the country from where the site is accessed (like google.com
does);
That would be cool, agreed. But it would put an extra premium on the
up-to-dateness of the translated pages. I think we can assume that
the Google translations are almost always in perfect sync!
2. Instead of http://gretl.sourceforge.net/gretl_portugues.html, we
could use a shorter URL like gretl.sourceforge.net/br (or pt, or es,
etc.) or even gretl.com/br.
Names such as "gretl_portugues.html" are rather verbose, yes. I'd be
happy to rename these files as "pt.html", "es.html" and so on. And
note that sf.net is an acceptable synonym for sourceforge.net, so
you'd have
gretl.sf.net/pt.html
(and br.html could be a symlink to pt.html if you like). However,
I'm not going to buy gretl.com! (If someone else wants to, that's
fine by me.)
Allin
9:26 a.m.
Em 18 de dezembro de 2012, Allin escreveu:
On Mon, 17 Dec 2012, Henrique Andrade wrote:
> Dear Allin,
>
> I like your proposal. Additionally, I would like to make some
> suggestions:
>
> 1. It would be nice if Gretl home page automatically recognizes
> the country from where the site is accessed (like google.com
> does);
That would be cool, agreed. But it would put an extra premium on the
up-to-dateness of the translated pages. I think we can assume that
the Google translations are almost always in perfect sync!
> 2. Instead of http://gretl.sourceforge.net/gretl_portugues.html, we
> could use a shorter URL like gretl.sourceforge.net/br (or pt, or es,
> etc.) or even gretl.com/br.
Names such as "gretl_portugues.html" are rather verbose, yes. I'd be
happy to rename these files as "pt.html", "es.html" and so on. And
note that sf.net is an acceptable synonym for sourceforge.net, so
you'd have
gretl.sf.net/pt.html
This is good, but IMHO I think it would be better if we don't need to use
the "html" extension. Is it possible to change to gretl.sf.net/pt and put
the gretl.sf.net/br (as a simple mirror of the "pt" site)?
(and br.html could be a symlink to pt.html if you like). However,
I'm not going to buy gretl.com! (If someone else wants to, that's
fine by me.)
I really don't know the costs of a domain purchase, but I think we could
raise that money via donations ;-)
Another suggestion that I would like to make is to remove the Linux spe-
cific download options from the homepage by replacing it for a menu
where the user could choose the appropriate OS. Please take a look at
the attached PNG files where I illustrate this idea.
Best,
Henrique Andrade*
*
9:31 p.m.
Dear Allin,
Today I updated the Portuguese homepage. Could you please upload it
to the SourceForge server?
Best,
Henrique
2013/1/7 Henrique Andrade <henrique.coelho(a)gmail.com>
Em 18 de dezembro de 2012, Allin escreveu:
On Mon, 17 Dec 2012, Henrique Andrade wrote:
>
> > Dear Allin,
> >
> > I like your proposal. Additionally, I would like to make some
> > suggestions:
> >
> > 1. It would be nice if Gretl home page automatically recognizes
> > the country from where the site is accessed (like google.com
> > does);
>
> That would be cool, agreed. But it would put an extra premium on the
> up-to-dateness of the translated pages. I think we can assume that
> the Google translations are almost always in perfect sync!
>
> > 2. Instead of http://gretl.sourceforge.net/gretl_portugues.html, we
> > could use a shorter URL like gretl.sourceforge.net/br (or pt, or es,
> > etc.) or even gretl.com/br.
>
> Names such as "gretl_portugues.html" are rather verbose, yes. I'd be
> happy to rename these files as "pt.html", "es.html" and so on.
And
> note that sf.net is an acceptable synonym for sourceforge.net, so
> you'd have
>
> gretl.sf.net/pt.html
>
This is good, but IMHO I think it would be better if we don't need to use
the "html" extension. Is it possible to change to gretl.sf.net/pt and put
the gretl.sf.net/br (as a simple mirror of the "pt" site)?
> (and br.html could be a symlink to pt.html if you like). However,
> I'm not going to buy gretl.com! (If someone else wants to, that's
> fine by me.)
>
I really don't know the costs of a domain purchase, but I think we could
raise that money via donations ;-)
Another suggestion that I would like to make is to remove the Linux spe-
cific download options from the homepage by replacing it for a menu
where the user could choose the appropriate OS. Please take a look at
the attached PNG files where I illustrate this idea.
Best,
Henrique Andrade*
*
--
Henrique Andrade*
*
2:18 a.m.
Hello all (translators),
I admit I haven't read the thread thoroughly, but as a translator (for
German) who hasn't translated the web pages, let me state my opinion: If
a translator chooses to translate also the web pages, it is his (I don't
think there are women in this case) job to check the changes on the site
and to keep the translated pages up to date. Personally I predicted I
wouldn't be able to do this and therefore I did not translate the web
pages (or the manual). IMHO it's counterproductive if Allin has to deal
with these things, it's really a waste of resources.
So if translated web pages are lagging significantly, throw them out.
It's always possible to get them back once they're in shape again,
there's nothing irreversible there.
Thanks,
sven
Am 18.12.2012 00:33, schrieb Allin Cottrell:
On Mon, 17 Dec 2012, Allin Cottrell wrote:
> I'd be very glad to receive suggestions on the best way of keeping
> the translations reasonably up to date.
After thinking about it, here's one proposal. All the specific
timings below are notional and subject to debate.
1) I designate a subset of the gretl web pages in CVS as "core"
pages and publish this list.
2) I set up a cron (automated batch) job to scan the translations of
the core pages each week. If a translation is found to be more than
three months behind the English version then an automatic email is
sent to its author, saying that if the translation is not updated
within a week it will be replaced by the English version.
3) The cron job detects if a page was flagged, as decribed above,
the previous week and has not been updated. If so, it uploads the
English page to sourceforge in place of the translation. (For
example, if the language in question is "xx", it overwrites the
translation, gretl_foo_xx.html, with the English version,
gretl_foo.html.) It could also send out a second email saying that
this has happened.
4) The cron job keeps a list of any pages that have been replaced in
this way, and if an updated version lands in CVS the translated page
is restored on sourceforge.
Allin
_______________________________________________
Gretl-devel mailing list
Gretl-devel(a)lists.wfu.edu
http://lists.wfu.edu/mailman/listinfo/gretl-devel
4:36 a.m.
Just another thought.
How about if a banner in English stating that the page might be
outdated and recommending the English page?
This way if the cron job sees changes in the page it would remove the
banner, and the original translation wouldn't be lost.
Helio
12:19 p.m.
On Tue, 18 Dec 2012, Sven Schreiber wrote:
Hello all (translators),
I admit I haven't read the thread thoroughly, but as a translator (for
German) who hasn't translated the web pages, let me state my opinion: If
a translator chooses to translate also the web pages, it is his (I don't
think there are women in this case) job to check the changes on the site
and to keep the translated pages up to date.
I basically agree. On the other hand, I realize that people
may have good intentions to keep things up to date, but also
have other priorities and have difficulty finding the time to
check for changes they "ought" to be tracking.
And a little automation may help here, e.g. a bot that sends
out a monthly status report on the translated pages. I've
written a prototype for this. Here's a sample report (with the
actual name of the language in question removed!).
filename lag
template/gretl_somelang_pat.html 14.3 months
template/osx_pat_xx.html 4.2 years
template/win32_pat_xx.html 2.5 months
template/mac-intel_pat_xx.html (not present)
template/mac-ppc_pat_xx.html (not present)
depend_xx.html 3.7 years
gretl_data_xx.html 2.9 years
"lag" indicates the time-lag relative to the current English
version. The set of pages covered is confined to those that
have download information that should be kept up to date (and
is not fully automated).
Allin
6:59 a.m.
On 18/12/12 18:19, Allin Cottrell wrote:
On Tue, 18 Dec 2012, Sven Schreiber wrote:
> Hello all (translators),
>
> I admit I haven't read the thread thoroughly, but as a translator (for
> German) who hasn't translated the web pages, let me state my opinion: If
> a translator chooses to translate also the web pages, it is his (I don't
> think there are women in this case) job to check the changes on the site
> and to keep the translated pages up to date.
I basically agree. On the other hand, I realize that people
may have good intentions to keep things up to date, but also
have other priorities and have difficulty finding the time to
check for changes they "ought" to be tracking.
Sorry for the delay in responding to this. May be I am one of these
people, but the question is not only that our good intentions are not
put in practice. May be we put in practice for 2, 3 or 5 years but time
goes by for everybody and our circumstances change. Maybe after five
years you're busy with other things more than you expected.
Furthermore it is really more difficult to update textual pages as the
latex/xml pages of the manuals or the web pages than the .po files of
the program itself. In that task you need to work with four files open
at the same time and it is difficult to detect the changes and put the
new translations in the correct place. Only for opening all the correct
files and doing some small changes it requires much time. So this is not
as updating a .po file (that usually I do it in 15 minutes), you need to
plan because it may require several hours of work.
There is a project "po4a" (po for anything) whose goal is to help with
these type of translations.
I did some testing with it and seemed to work well. Do you think it
would be possible to put it in practice for us?
If not, the method proposed by Allin, seems rather practical for me.
And a little automation may help here, e.g. a bot that sends
out a monthly status report on the translated pages. I've
written a prototype for this. Here's a sample report (with the
actual name of the language in question removed!).
filename lag
template/gretl_somelang_pat.html 14.3 months
template/osx_pat_xx.html 4.2 years
template/win32_pat_xx.html 2.5 months
template/mac-intel_pat_xx.html (not present)
template/mac-ppc_pat_xx.html (not present)
depend_xx.html 3.7 years
gretl_data_xx.html 2.9 years
"lag" indicates the time-lag relative to the current English
version. The set of pages covered is confined to those that
have download information that should be kept up to date (and
is not fully automated).
Allin
_______________________________________________
Gretl-devel mailing list
Gretl-devel(a)lists.wfu.edu
http://lists.wfu.edu/mailman/listinfo/gretl-devel
--
Ignacio Diaz-Emparanza
DEPARTAMENTO DE ECONOMÍA APLICADA III (ECONOMETRÍA Y ESTADÍSTICA)
UPV/EHU Avda. Lehendakari Aguirre, 83 | 48015 BILBAO
T.: +34 946013732 | F.: +34 946013754
www.ehu.es/ignacio.diaz-emparanza/
www.ea3.ehu.es
7:12 a.m.
On Thu, 3 Jan 2013, Ignacio Diaz-Emparanza wrote:
[I]t is really more difficult to update textual pages as the
latex/xml pages of the manuals or the web pages than the .po files
of the program itself.
Yes, I can see that.
There is a project "po4a" (po for anything) whose goal is
to help
with these type of translations. I did some testing with it and
seemed to work well. Do you think it would be possible to put it
in practice for us?
I'll look into that.
Allin
8:34 a.m.
Em 3 de janeiro de 2013, Allin escreveu:
On Thu, 3 Jan 2013, Ignacio Diaz-Emparanza wrote:
> [I]t is really more difficult to update textual pages as the
> latex/xml pages of the manuals or the web pages than the .po files
> of the program itself.
Yes, I can see that.
Dear Ignacio and Allin, we discussed the possibility to use .po files
for doc translations some time ago:
http://lists.wfu.edu/pipermail/gretl-devel/2009-November/002171.html
Our friend Ivan Sopov already had built a config-file for po4a utility
that generates .pot and .po from the XML files. Please take a look
at the message:
http://lists.wfu.edu/pipermail/gretl-devel/2009-December/002273.html
Or go directly to the file:
http://www.sopovs.com/gretl/po4a_config.txt
There is a project "po4a" (po for anything) whose goal is
to help
> with these type of translations. I did some testing with it and
> seemed to work well. Do you think it would be possible to put it
> in practice for us?
I'll look into that.
I strongly agree with Ignacio and I believe that if we could pave a
better and easier way for translations we will translate more
documentation ;-)
Best regards,
Henrique Andrade*
*
9:06 a.m.
Here are my thoughts on this.
I've attempted to use the system Henrique described, and lost the
translation that I have done (1 hour work). So, I would like that
whatever system we use, to have:
- Working offline using the CVS shared files.
- Keeping the XML file format. (because Allin has it in a state of the
art for Doc and Help production).
I am keeping the PT translations in synch. I use diff scripts to and
the validate tool to see what commands (and functions) Allin and Jack
have changed, and then edit the PT files side-by-side with the EN
ones.
(I can share the scripts if you want)
For the PDF docs, I have the PT structure set and most of the files
are straight copied from EN.
I am in favour of having a better system for translation, that might
bring more people to this effort, but I don't want to loose what is
already translated.
Cheers,
Hélio
On Thu, Jan 3, 2013 at 1:34 PM, Henrique Andrade
<henrique.coelho(a)gmail.com> wrote:
Em 3 de janeiro de 2013, Allin escreveu:
> On Thu, 3 Jan 2013, Ignacio Diaz-Emparanza wrote:
>
> > [I]t is really more difficult to update textual pages as the
> > latex/xml pages of the manuals or the web pages than the .po files
> > of the program itself.
>
> Yes, I can see that.
Dear Ignacio and Allin, we discussed the possibility to use .po files
for doc translations some time ago:
http://lists.wfu.edu/pipermail/gretl-devel/2009-November/002171.html
Our friend Ivan Sopov already had built a config-file for po4a utility
that generates .pot and .po from the XML files. Please take a look
at the message:
http://lists.wfu.edu/pipermail/gretl-devel/2009-December/002273.html
Or go directly to the file:
http://www.sopovs.com/gretl/po4a_config.txt
> > There is a project "po4a" (po for anything) whose goal is to help
> > with these type of translations. I did some testing with it and
> > seemed to work well. Do you think it would be possible to put it
> > in practice for us?
>
> I'll look into that.
I strongly agree with Ignacio and I believe that if we could pave a
better and easier way for translations we will translate more
documentation ;-)
Best regards,
Henrique Andrade
_______________________________________________
Gretl-devel mailing list
Gretl-devel(a)lists.wfu.edu
http://lists.wfu.edu/mailman/listinfo/gretl-devel
10:03 a.m.
Em 3 de janeiro de 2013, Hélio escreveu:
Here are my thoughts on this.
I've attempted to use the system Henrique described, and lost the
translation that I have done (1 hour work). So, I would like that
whatever system we use, to have:
- Working offline using the CVS shared files.
- Keeping the XML file format. (because Allin has it in a state of the
art for Doc and Help production).
Dear Hélio, my suggestion is to use only the po4a tool to keep stuff
updated. The use of Launchpad is not (in my humble opinion) neces-
sary at this point ;-)
I am keeping the PT translations in synch. I use diff scripts to and
the validate tool to see what commands (and functions) Allin and Jack
have changed, and then edit the PT files side-by-side with the EN
ones.
(I can share the scripts if you want)
This is good! Unfortunately I did not get a good framework for translating
as this you set. I need to compare everything manually.
For the PDF docs, I have the PT structure set and most of the files
are straight copied from EN.
I am in favour of having a better system for translation, that might
bring more people to this effort, but I don't want to loose what is
already translated.
I'm not sure about this, but I think one could "convert" all the xml files
into po (even the already translated files). Am I right?
Um abraço,
Henrique Andrade*
*
10:10 a.m.
On Thu, 3 Jan 2013, Henrique Andrade wrote:
I'm not sure about this, but I think one could
"convert" all the xml files
into po (even the already translated files). Am I right?
XML must remain the canonical format. This is required for applying
XSLT to generate TeX and the "online" help files.
I haven't yet looked at po4a, but I think we would need a two-way
automatic converter, between XML and po.
Allin
4214
days inactive
4240
days old
15 comments
5 participants
participants (5)
-
Allin Cottrell -
Henrique Andrade -
Hélio Guilherme -
Ignacio Diaz-Emparanza -
Sven Schreiber