On Fri, Oct 01, 2004 at 10:04:40AM +0100, Miha Staut wrote:
Hi!
I am willing to translate GRASS in Slovenian language.
The problem is that I am very new to this kind of
task. Markus promised no programming skills are
necessary. Is there an easy step by step howto on the
net.
The translation procedure may be further improved in future,
but it is already much simpler than it ever was for 5.0.
Note: Only a few messages are currently extracted as
the 'gettext' macros have to be integrated into 5.7.
But to warm up you may start to translate the 3xx messages
which are already extractable.
> I am willing to translate GRASS in Slovenian language.
> The problem is that I am very new to this kind of
> task. Markus promised no programming skills are
> necessary. Is there an easy step by step howto on the
> net.
if we change a _("text string") in the original source code, do we need
to go though all the translation sets and adjust them too? or can the
"make update-po" step somehow figure this out?
If I do that but don't have the correct encodings installed on my system
(eg for Russian) is this likely to mess up the entire translation file?
> > I am willing to translate GRASS in Slovenian language.
> > The problem is that I am very new to this kind of
> > task. Markus promised no programming skills are
> > necessary. Is there an easy step by step howto on the
> > net.
>
> OK, I have added a new web page:
> http://grass.itc.it/i18n.html
question:
if we change a _("text string") in the original source code, do we need
to go though all the translation sets and adjust them too? or can the
"make update-po" step somehow figure this out?
You don't *need* to do anything. If the string can't be found in the
message catalogue, the original (English) string will be returned.
Apart from that, keeping the message catalogues in sync with the
source code is the responsibility of the translators, not of the
programmers.
If I do that but don't have the correct encodings installed on my system
(eg for Russian) is this likely to mess up the entire translation file?
Don't try to edit message catalogues for unfamiliar languages,
particularly those in unfamiliar encodings.
if we change a _("text string") in the original source code, do we need
to go though all the translation sets and adjust them too? or can the
"make update-po" step somehow figure this out?
You don't *need* to do anything. If the string can't be found in the
message catalogue, the original (English) string will be returned.
Apart from that, keeping the message catalogues in sync with the
source code is the responsibility of the translators, not of the
programmers.
Does that mean that the English versions of all the messages are set in stone in the source code while the translations can be changed freely without affecting anything else? I'm not sure if I understand it correctly, but if all the other translations are based on the exact form of words of the English message, then presumably it would not be a good idea for developers to ever try and change the messages any more (to make them less confusing or more informative), as the translations would not then work? Or are the messages identified by the line they occur in the
source file or some other mechanism like that?
>> question:
>>
>> if we change a _("text string") in the original source code, do we need
>> to go though all the translation sets and adjust them too? or can the
>> "make update-po" step somehow figure this out?
>
> You don't *need* to do anything. If the string can't be found in the
> message catalogue, the original (English) string will be returned.
>
> Apart from that, keeping the message catalogues in sync with the
> source code is the responsibility of the translators, not of the
> programmers.
Does that mean that the English versions of all the messages are set in
stone in the source code while the translations can be changed freely
without affecting anything else? I'm not sure if I understand it
correctly, but if all the other translations are based on the exact form
of words of the English message, then presumably it would not be a good
idea for developers to ever try and change the messages any more (to make
them less confusing or more informative), as the translations would not
then work? Or are the messages identified by the line they occur in the
source file or some other mechanism like that?
The string literal in the source code is used as the key into the
message catalogue, so if you change the string, all of the .po files
have to be changed accordingly.
However, if you want to change the string which is used for English
locales without changing the source code, you can just create an
English message catalogue.
On Sat, Oct 02, 2004 at 04:27:49PM +1200, Hamish wrote:
> > I am willing to translate GRASS in Slovenian language.
> > The problem is that I am very new to this kind of
> > task. Markus promised no programming skills are
> > necessary. Is there an easy step by step howto on the
> > net.
>
> OK, I have added a new web page:
> http://grass.itc.it/i18n.html
question:
if we change a _("text string") in the original source code,
^^ ^
Related question: It's a pretty hard job to change all the message
strings manually. It there a way to (semi-)automate that?
> > > I am willing to translate GRASS in Slovenian language.
> > > The problem is that I am very new to this kind of
> > > task. Markus promised no programming skills are
> > > necessary. Is there an easy step by step howto on the
> > > net.
> >
> > OK, I have added a new web page:
> > http://grass.itc.it/i18n.html
>
>
> question:
>
> if we change a _("text string") in the original source code,
^^ ^
Related question: It's a pretty hard job to change all the message
strings manually. It there a way to (semi-)automate that?
Not really.
There's no way that an automated process can realistically determine
whether or not a given string should be translated. Strings which are
only shown to the user can be translated, while strings which are part
of a defined data format can't.
Also, if a string is meant to be a compile-time constant (e.g. an
array initialiser), the expression has to be a direct string literal,
not a string expression.
