Hi,
A typo in src/extension/extension.cpp:
beacuse
Double colon in src/extension/dependency.cpp:
out_file << _("Dependency::") << std::endl;
Also a question: in this piece of code from src/extension/dependency.cpp:
gchar const * Dependency::_location_str[] = { N_("path"), N_("extensions"), N_("absolute")
does "path" mean "filesystem path" (as opposed to "vector path")?
Arpad Biro
__________________________________ Do you Yahoo!? Yahoo! Mail - 250MB free storage. Do more. Manage less. http://info.mail.yahoo.com/mail_250
On Thu, 2005-01-27 at 15:13 -0800, Arpad Biro wrote:
A typo in src/extension/extension.cpp:
beacuse
Correct.
Double colon in src/extension/dependency.cpp:
out_file << _("Dependency::") << std::endl;
I put the double colon here to distinguish it from the other lines that are being printed. It was intentional, but I don't care that they stick around.
Also a question: in this piece of code from src/extension/dependency.cpp:
gchar const * Dependency::_location_str[] = { N_("path"), N_("extensions"), N_("absolute")
does "path" mean "filesystem path" (as opposed to "vector path")?
Actually "path" here means "The Path" so the environment variable which is $PATH from the shell. I guess a term like "search path" or something similar would also apply. It is critical that the English terms here don't change, they are used for the values inside the .inx files.
--Ted
if you dont want them changing might be wise not to make them translatable.
just a thought.
John
On Wed, 02 Feb 2005 00:00:45 -0800, Ted Gould <ted@...11...> wrote:
On Thu, 2005-01-27 at 15:13 -0800, Arpad Biro wrote:
A typo in src/extension/extension.cpp:
beacuse
Correct.
Double colon in src/extension/dependency.cpp:
out_file << _("Dependency::") << std::endl;
I put the double colon here to distinguish it from the other lines that are being printed. It was intentional, but I don't care that they stick around.
Also a question: in this piece of code from src/extension/dependency.cpp:
gchar const * Dependency::_location_str[] = { N_("path"), N_("extensions"), N_("absolute")
does "path" mean "filesystem path" (as opposed to "vector path")?
Actually "path" here means "The Path" so the environment variable which is $PATH from the shell. I guess a term like "search path" or something similar would also apply. It is critical that the English terms here don't change, they are used for the values inside the .inx files.
--Ted
Hi,
gchar const * Dependency::_location_str[] = { N_("path"), N_("extensions"), N_("absolute")
Actually "path" here means "The Path" so the environment variable which is $PATH from the shell. I guess a term like "search path" or something similar would also apply. It is critical that the English terms here don't change, they are used for the values inside the .inx files.
What do you mean? "Do not translate them to any other language", or "do not modify the original English strings in the source code"?
Arpad Biro
__________________________________ Do you Yahoo!? Yahoo! Mail - 250MB free storage. Do more. Manage less. http://info.mail.yahoo.com/mail_250
On Wed, Feb 02, 2005 at 01:29:44PM -0800, Arpad Biro wrote:
gchar const * Dependency::_location_str[] = { N_("path"), N_("extensions"), N_("absolute")
Actually "path" here means "The Path" so the environment variable which is $PATH from the shell. I guess a term like "search path" or something similar would also apply. It is critical that the English terms here don't change, they are used for the values inside the .inx files.
What do you mean? "Do not translate them to any other language", or "do not modify the original English strings in the source code"?
From the look of the code, I actually don't think these should be
translatable strings... They're used in repr attr comparisons. I've removed them from translation unless Ted says otherwise. (Not that they were used in their translated forms: the _N tags just mark them, but don't change them.) Any _N'd strings still need to have _() called on them, which wasn't happening in the code, so this didn't break anything. It just wasn't Right.
On Wed, Feb 02, 2005 at 01:29:44PM -0800, Arpad Biro wrote:
What do you mean? "Do not translate them to any other language", or "do not modify the original English strings in the source code"?
I was meaning do not modify the English strings in the source code. Sorry for not being more clear.
On Wed, 2005-02-02 at 14:11 -0800, Kees Cook wrote:
From the look of the code, I actually don't think these should be translatable strings... They're used in repr attr comparisons. I've removed them from translation unless Ted says otherwise. (Not that they were used in their translated forms: the _N tags just mark them, but don't change them.) Any _N'd strings still need to have _() called on them, which wasn't happening in the code, so this didn't break anything. It just wasn't Right.
Actually, if you look at the end of the file they are used with the _() around them -- this is for the logging output for the log file.
I'm thinking that, perhaps, the translation should be something like this:
"path" -> "newlang (path)"
The reason being is that "path" is what the field should be in the XML file. So, if someone is debugging their .inx file they would want to know the correct value for the attribute, but a user might want to know what it actually means. Is there some other standard convention for this?
--Ted
On Wed, Feb 02, 2005 at 07:47:05PM -0800, Ted Gould wrote:
I'm thinking that, perhaps, the translation should be something like this:
"path" -> "newlang (path)"
The reason being is that "path" is what the field should be in the XML file. So, if someone is debugging their .inx file they would want to know the correct value for the attribute, but a user might want to know what it actually means. Is there some other standard convention for this?
Hm. It doesn't feel right to push output logic into the translations. Seems sensible, but I worry it'll create more confusion than help in translations. Maybe make a quick hashmap or function to spit out the english you want, and then those strings can be translated?
participants (4)
-
Arpad Biro -
john cliff -
Kees Cook -
Ted Gould