2:15 p.m.
I have a few questions/issues to report that I encountered while
updating the Turkish translation:
1)- In the regression output, Turkish translation uses "Hannan-Quinn
Information Criterion" (line 977) which is too long resulting in the
defaulting to the old view. The English translation seems to use the
"Hannan-Quinn" in line 989.
2)- In the "gretl:forecasts" window the first column is labeled "obs"
The translation for "Obs" is defined in the po file line 1071. Can
this be used in this particular case please? It looks really bad
otherwise.
3)- Line 1721 is changed to "Produce forecast for" This type of
expressions are very awkward for translation into Turkish where the
subject usually has to be in the beginning and the verb is at the end.
...and where do I get this string in the program?
4)- The line 2261:
For %g\\%% confidence intervals, $z(%g) = %.2f$\n
\n
Here is the "\\" for Latex? How should I the percentage sign in front of %g
Similarly, in line 2263, would it be OK to translate like this?
%g\\%% interval
as
\\%% %g aralığı
5)- When I copy the contents of a window and paste it I get problems
with the Turkish characters. Below I paste the contents of the ANOVA
window:
Varyans \Uffffffffz\Uffffffffsi:
Kareler toplam\Uffffffff sd Ortalama
Ba\Uffffffff\Uffffffff 4,36357e+06 2 2,18179e+06
Kal\Uffffffff 1,67307e+08 37 4,5218e+06
Toplam 1,7167e+08 39 4,63973e+06
R^2 = 4,36357e+06 / 1,7167e+08 = 0,025418
F(2, 37) = 2,18179e+06 / 4,5218e+06 = 0,482504 [p-de\Uffffffff 0,6211]
These are all the issues that I encounered.
Cheers
Talha
--
"Remember not only to say the right thing in the right place, but far
more difficult still, to leave unsaid the wrong thing at the tempting
moment." - Benjamin Franklin (1706-1790)
--
12:25 a.m.
Talha wrote:
I have a few questions/issues to report that I encountered while
updating the Turkish translation:
1)- In the regression output, Turkish translation uses
"Hannan-Quinn
Information Criterion" (line 977) which is too long resulting in the
defaulting to the old view. The English translation seems to use the
"Hannan-Quinn" in line 989.
Sorry, that was a logic bug: my heuristic for "string is not
translated" was that the original msgid compares equal with the
string returned by gettext. but that's not a valid test for msgid
"Hannan-Quinn". Fixed in CVS.
2)- In the "gretl:forecasts" window the first column is
labeled "obs"
The translation for "Obs" is defined in the po file line 1071. Can
this be used in this particular case please? It looks really bad
otherwise.
Yes, now done.
3)- Line 1721 is changed to "Produce forecast for" This
type of
expressions are very awkward for translation into Turkish where the
subject usually has to be in the beginning and the verb is at the end.
...and where do I get this string in the program?
The context is line 2384 in gui2/dialogs.c: the user has estimated a
model with a differenced dependent variable, and under "Forecast"
he/she is given the option of forecasting either the difference or
the level. Schematically, the relevant bit of the dialog looks
like this (ASCII art):
Produce forecast for (*) d_depvar [difference]
( ) depvar [level]
where "( )" indicates a "radio button". If you have a suggestion
for a more translation-friendly way of expressing this choice,
I'll certainly listen.
4)- The line 2261:
For %g\\%% confidence intervals, $z(%g) = %.2f$\n
\n
Here is the "\\" for Latex?
Yes, percent signs have to be backslash-escaped in TeX.
How should I the percentage sign in front of %g
The '%' in '%g' is a C printf format specifier; just carry that
over literally.
Similarly, in line 2263, would it be OK to translate like this?
%g\\%% interval
as
\\%% %g aralığı
Yes, if (say) "90% interval" is written as "% 90 aral" in Turkish.
5)- When I copy the contents of a window and paste it I get problems
with the Turkish characters.
What application are you pasting into? And what character set
is that application using? GTK uses UTF-8 exclusively. "Legacy"
apps that don't use UTF-8 will probably show the sort of mess that
you got.
Allin.
1:01 a.m.
On Fri, 10 Apr 2009, Allin Cottrell wrote:
> 5)- When I copy the contents of a window and paste it I get
problems
> with the Turkish characters.
What application are you pasting into? And what character set
is that application using? GTK uses UTF-8 exclusively. "Legacy"
apps that don't use UTF-8 will probably show the sort of mess that
you got.
Actually, that's not quite true: if you copy-n-paste using Edit,
Copy (as plain text) in gretl, and Edit, Paste in the target app,
then if the target app is not using UTF-8 (and is correctly
"advertising" the character set it does use) the text should be
automatically converted. I just checked this by copying from
gretl into Nedit, which doesn't do UTF-8. (There are no problems
copying into gedit.)
But things will come out right for Turkish text only if the font
that the target app is using supports all the Turkish glyphs. As
it happens, Nedit on my system was using ISO-8859-1, so some of
the Turkish characters did not appear properly (e.g. the
s-cedilla, which is not in ISO-8859-1).
Allin.
6:53 a.m.
Thanks very much for the reply and the fixes.
Produce forecast for (*) d_depvar [difference]
( ) depvar [level]
...for a more translation-friendly way of expressing this choice,
I'll certainly listen.
How about "forecasts produced:"? This type of
presentation with the
colons looks better for Turkish but I don't know if it is better or
worse for other languages. Are there any opinions or suggestions from
the other developers/translators?
> Here is the "\\" for Latex?
Yes, percent signs have to be backslash-escaped in TeX.
Thanks for the
clarification.
> 5)- When I copy the contents of a window and paste it I get
problems
> with the Turkish characters.
What application are you pasting into? And what character set
is that application using?
I pasted into gmail using firefox. I get bad characters
pasting into
kwrite and openoffice also.
Well, the real reason I used it was to show the vertical misalignment
of the ANOVA window output. I get this (after manually fixing the bad
characters):
Varyans cozumlemesi:
Kareler toplami sd Ortalama
Baglanim 3,35141e+06 1 3,35141e+06
Kalinti 5349,39 13 411,492
Toplam 3,35676e+06 14 258212
R^2 = 3,35141e+06 / 3,35676e+06 = 0,998406
F(1, 13) = 3,35141e+06 / 411,492 = 8144,53 [p-degeri 1,42e-19]
So the columns are always misaligned in this window. Is this due to a
translation problem? How can I fix this?
Finally, I have 2 more things:
1)- Line 1692: "Average of observations"
Line 1857: "Number of observations in average:"
Here gretl is refering to the mean right?
Since average generally means "some measure of central tendency
including but not limited to the mean," how about limiting the use of
the term average to phrases like "an average observation"?
2)- When specifying a model, the lag order window has the variable
"default." There is no single entry in the pot file for the term
"default" Can this be translatable also?
Best regards
Talha
--
“Remember not only to say the right thing in the right place, but far
more difficult still, to leave unsaid the wrong thing at the tempting
moment.” - Benjamin Franklin (1706-1790)
--
2:04 a.m.
On Mon, 13 Apr 2009, Talha Yalta wrote:
Thanks very much for the reply and the fixes.
> Produce forecast for (*) d_depvar [difference]
> ( ) depvar [level]
> ...for a more translation-friendly way of expressing this choice,
> I'll certainly listen.
How about "forecasts produced:"? This type of presentation with the
colons looks better for Turkish but I don't know if it is better or
worse for other languages. Are there any opinions or suggestions from
the other developers/translators?
That doesn't work very well for English; I'll wait to hear what
others have to say. But translate it as you think fit;
translations don't have to be literal if that runs counter to
idiom. The only thing is, "forecasts produced" sounds as if there
might be more than one, but there will only one: the dialog gives
a binary choice.
>> 5)- When I copy the contents of a window and paste it I get
problems
>> with the Turkish characters.
>
> What application are you pasting into? And what character set
> is that application using?
I pasted into gmail using firefox. I get bad characters pasting into
kwrite and openoffice also.
Pasting Turkish text from gretl into OpenOffice works fine here.
Is your locale setting something other than UTF-8? (Try typing
"locale" at a shell prompt.)
Well, the real reason I used it was to show the vertical
misalignment
of the ANOVA window output. I get this (after manually fixing the bad
characters):
Kareler toplami sd Ortalama
Baglanim 3,35141e+06 1 3,35141e+06
Kalinti 5349,39 13 411,492
Toplam 3,35676e+06 14 258212
R^2 = 3,35141e+06 / 3,35676e+06 = 0,998406
F(1, 13) = 3,35141e+06 / 411,492 = 8144,53 [p-degeri 1,42e-19]
So the columns are always misaligned in this window.
I see what you mean; I'll have to look into that.
Finally, I have 2 more things:
1)- Line 1692: "Average of observations"
Line 1857: "Number of observations in average:"
Here gretl is refering to the mean right?
Since average generally means "some measure of central tendency
including but not limited to the mean," how about limiting the use of
the term average to phrases like "an average observation"?
The second string occurs in the context of calculating a moving
average, which is always called by that name in English and never
a "moving mean". The first one could perhaps be modified, but
anyway feel free to translate it as "mean" if you like.
2)- When specifying a model, the lag order window has the variable
"default." There is no single entry in the pot file for the term
"default" Can this be translatable also?
OK, that's now marked for translation in CVS.
Allin.
6:11 a.m.
Thanks very much for the updates.
That doesn't work very well for English; I'll wait to hear
what
others have to say. But translate it as you think fit;
translations don't have to be literal if that runs counter to
idiom. The only thing is, "forecasts produced" sounds as if there
might be more than one, but there will only one: the dialog gives
a binary choice.
OK I fixed it.
Pasting Turkish text from gretl into OpenOffice works fine here.
Is your locale setting something other than UTF-8? (Try typing
"locale" at a shell prompt.)
I get:
LANG=tr_TR.UTF-8
LC_CTYPE="tr_TR.UTF-8"
LC_NUMERIC="tr_TR.UTF-8"
LC_TIME="tr_TR.UTF-8"
LC_COLLATE="tr_TR.UTF-8"
LC_MONETARY="tr_TR.UTF-8"
LC_MESSAGES="tr_TR.UTF-8"
LC_PAPER="tr_TR.UTF-8"
LC_NAME="tr_TR.UTF-8"
LC_ADDRESS="tr_TR.UTF-8"
LC_TELEPHONE="tr_TR.UTF-8"
LC_MEASUREMENT="tr_TR.UTF-8"
LC_IDENTIFICATION="tr_TR.UTF-8"
LC_ALL=tr_TR.UTF-8
Is there anything missing?
> So the columns are always misaligned in this window.
I see what you mean; I'll have to look into that.
Thanks.
Two more things:
1)- In line 731: "%s: expected an integer order." Here, is "order"
refering to power?
2)- Could you modify the about window so that it is possible to
provide an url for the translator also? In line 1345, I enter my name
and affiliation but my university page link does not work.
Sincerely
Talha
--
“Remember not only to say the right thing in the right place, but far
more difficult still, to leave unsaid the wrong thing at the tempting
moment.” - Benjamin Franklin (1706-1790)
--
11:52 p.m.
On Tue, 14 Apr 2009, Talha Yalta wrote:
> Pasting Turkish text from gretl into OpenOffice works fine
here.
> Is your locale setting something other than UTF-8? (Try typing
> "locale" at a shell prompt.)
I get:
LANG=tr_TR.UTF-8 ...
Is there anything missing?
No, that all looks fine. Then I can't understand why OpenOffice
won't handle UTF-8 text from GTK (gretl) correctly. Maybe it's
some weird lack of interoperability between GTK and KDE.
Two more things:
1)- In line 731: "%s: expected an integer order." Here, is "order"
refering to power?
No, to a lag order.
2)- Could you modify the about window so that it is possible to
provide an url for the translator also? In line 1345, I enter my name
and affiliation but my university page link does not work.
It would be magic if it did. No, this is not particularly easy to
do. I suppose I could put a special translatable string into the
gretl .pot file but it would probably be quite confusing to most
people.
Allin.
11:59 a.m.
> LANG=tr_TR.UTF-8 ...
> Is there anything missing?
No, that all looks fine. Then I can't understand why OpenOffice
won't handle UTF-8 text from GTK (gretl) correctly. Maybe it's
some weird lack of interoperability between GTK and KDE.
Maybe that's the
reason. I sometimes get this strange behaviour where
something I copied from firefox wont paste into openoffice but when I
select that from the Klipper applet, it pastes. Maybe related :-P
> refering to power?
No, to a lag order.
Thanks will make the adjustment.
It would be magic if it did. No, this is not particularly easy to
do. I suppose I could put a special translatable string into the
gretl .pot file but it would probably be quite confusing to most
people.
Adding an optional "translator url" field to be printed just
below the
translator credits strings would be nice IMHO. An optional string for
explanations was recently added to the new regression output window as
well.
Cheers
Talha
--
“Remember not only to say the right thing in the right place, but far
more difficult still, to leave unsaid the wrong thing at the tempting
moment.” - Benjamin Franklin (1706-1790)
--
11:56 p.m.
On Wed, 15 Apr 2009, Talha Yalta wrote:
Adding an optional "translator url" field to be printed
just
below the translator credits strings would be nice IMHO. An
optional string for explanations was recently added to the new
regression output window as well.
Hmm, that's my point. If you look at all the gretl translations
you'll find that the results are mixed on that "optional string".
Adding "translatable strings that are not really strings for
translation" is problematic. It's an attempt to use gettext for
something that it was not designed for, and I'm not surprised that
some translators get confused, producing odd-looking results.
Allin.
5:49 a.m.
> Adding an optional "translator url" field to be printed
just
> below the translator credits strings would be nice IMHO. An
> optional string for explanations was recently added to the new
> regression output window as well.
Hmm, that's my point. If you look at all the gretl translations
you'll find that the results are mixed on that "optional string".
Adding "translatable strings that are not really strings for
translation" is problematic. It's an attempt to use gettext for
something that it was not designed for, and I'm not surprised that
some translators get confused, producing odd-looking results.
I see. The Turkish
translation makes a nice (IMHO) use of that string
and looks good doing that. I haven't checked the other translations
but I think supporting language specific remarks or explanations in
certain output windows is useful. It would be nice if other
developers/translators commented on this issue.
Cheers
Talha
--
“Remember not only to say the right thing in the right place, but far
more difficult still, to leave unsaid the wrong thing at the tempting
moment.” - Benjamin Franklin (1706-1790)
--
6381
days inactive
6387
days old
9 comments
2 participants
participants (2)
-
Allin Cottrell -
Talha Yalta