Re: po: fixed remaining Slovenian true positives in the winepo error report
On Wednesday 22 of February 2012 18:16:20 Francois Gouget wrote:
On Wed, 22 Feb 2012, Jaka Kranjc wrote: [...]
You mean that all the 'not translated' strings are actually translated and just happen to be the same as in English, right? I can add them.
Exactly.
Done. Great.
I also swapped wine-patches with wine-devel to keep the noise down.
So in English you'd end up with something like this:
Error; Paper jam; or Initialising; Default Printer; I/O Active;
So what you're saying is that: * There is no systematic conversion of semicolons to commas in Slovenian. * In Slovenian the strings above should definitely use a comma because it's used as a list separator. * The English string should maybe use a comma too? This may require some supporting arguments... So if I understand correctly, parts of this composite get choped and concatenated and then printed as a sequence. Lacking full sentences, semicolons *are* a good choice for Slovenian in this case too. Commas would be fitting for proper "etc" lists.
This brings up another can of worms though; capitalisation. We don't use title case at all, so these translation have the wrong case. Well, except for the first one being printed, but that is runtime knowledge, so we can't really fix it well. Gettext has no provisions for this (or gender or ...), so all that comes to mind is autocapitalisation depending on the locale, but that is probably ugly and I doubt it would work with more exotic scripts (but not sure if any would need it).
So no, in general we do not substitute semicolons, but it depends on the original msgid context. Most translators are serious grammar nazis, so they/we tend to ignore mistakes in the original string.
Don't!
At least for Wine any issue in the English string should be fixed or reported so it can be fixed as early as possible (preferably before it has been translated into 20 other languages). Of course I'm saying that but being in string freeze we would not be able to fix strings right now. But if I saw such reports on wine-devel I'd make sure they are acted upon after the release. Oh, I know, didn't mean to suggest inaction. But in a lot of cases, it comes down to preference, style or language perception. Plus the fact that inspecting the original's validity almost always requires the ability to read code, which most translators lack and which is hard to access if they work via online translation tools.
Re usage strings: is there no 80 column limit imposed? I saw even some original strings were longer. LP -- To err is humor
On Wed, 22 Feb 2012, Jaka Kranjc wrote: [...]
So if I understand correctly, parts of this composite get choped and concatenated and then printed as a sequence. Lacking full sentences, semicolons *are* a good choice for Slovenian in this case too. Commas would be fitting for proper "etc" lists.
This brings up another can of worms though; capitalisation. We don't use title case at all, so these translation have the wrong case. Well, except for the first one being printed, but that is runtime knowledge, so we can't really fix it well. Gettext has no provisions for this (or gender or ...), so all that comes to mind is autocapitalisation depending on the locale, but that is probably ugly and I doubt it would work with more exotic scripts (but not sure if any would need it).
I don't think we really care about capitalization in this specific case (or that it can be handled right anyway). So would the attached patch work? [...]
Re usage strings: is there no 80 column limit imposed? I saw even some original strings were longer.
If no line feed is hardcoded then the line will wrap at the 80th column. The line feeds are only there to ensure words are not cut in the middle. I suspect the authors of the command line tools did not care about that. Or they did not want to hardcode line wrapping at 80 columns when the terminal may be wider or narrower. And that issue was probably overlooked in a number of cases too. So these are probably all contributing factors to the current situation. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ f u kn rd ts, ur wy 2 gky 4 ur wn gd.
On Saturday 25 of February 2012 18:54:15 Francois Gouget wrote:
On Wed, 22 Feb 2012, Jaka Kranjc wrote: [...]
This brings up another can of worms though; capitalisation. We don't use title case at all, so these translation have the wrong case. Well, except for the first one being printed, but that is runtime knowledge, so we can't really fix it well. Gettext has no provisions for this (or gender or ...), so all that comes to mind is autocapitalisation depending on the locale, but that is probably ugly and I doubt it would work with more exotic scripts (but not sure if any would need it).
I don't think we really care about capitalization in this specific case (or that it can be handled right anyway).
So would the attached patch work? Sure.
Re usage strings: is there no 80 column limit imposed? I saw even some original strings were longer.
If no line feed is hardcoded then the line will wrap at the 80th column. The line feeds are only there to ensure words are not cut in the middle. I suspect the authors of the command line tools did not care about that. Or they did not want to hardcode line wrapping at 80 columns when the terminal may be wider or narrower. And that issue was probably overlooked in a number of cases too. So these are probably all contributing factors to the current situation. This is the reason we have some extra newlines in usage strings. I saw you removed them as part of one of the patches today, but that's potentially a bad idea. They use a placeholder for the file name and you know how long they can get, especially if the dir name isn't stripped first. The extra newline saved a few characters to make it less likely to wrap.
Probably it is best to reword the original string to not use the filename in the middle of a sentence and then put it into a separate line. LP -- To err is humor
On Sun, 26 Feb 2012, Jaka Kranjc wrote: [...]
This is the reason we have some extra newlines in usage strings. I saw you removed them as part of one of the patches today, but that's potentially a bad idea. They use a placeholder for the file name and you know how long they can get, especially if the dir name isn't stripped first. The extra newline saved a few characters to make it less likely to wrap.
Not in the Slovenian translation then? However in the places where I did the translation line length matched the English line to with a few characters so I'd say it's not a significant factor. But if you have specific concerns let me know.
Probably it is best to reword the original string to not use the filename in the middle of a sentence and then put it into a separate line.
The best is to not hardcode wrapping. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ I haven't lost my mind, it's backed up on tape around here somewhere...
participants (2)
-
Francois Gouget -
Jaka Kranjc