Re: [PATCH] cmd: Consistently wrap lines to 75 characters.
On Fri, 3 Jul 2015, Alex Henrie wrote:
75 characters is the maximum length of a line before gettext breaks it, so this convention will cause each translatable string to fit snugly into the po files. It's also about what we were doing anyway, just not consistently.
I think this patch and particularly its justification does not make any sense. The command line tool messages were wrapped to the typical width of a terminal: 80 characters. So with this change the messages now take more lines and lose in readability for the user. So now we gettext does not wrap the messages as much in the PO files. But that's totally irrelevant and invisible to the users. It's also totally irrelevant and invisible to a translator as soon as he uses a tool like poedit or a web GUI like Pootle. So what we have here is a change made solely to make things look a bit nicer to the few developers who look at PO files, at the cost of making them slightly worse for our users. Not a good tradeoff in my book and never a good justification for a patch.
I removed Hebrew "translations" of cmd.rc that were just copies of the English strings,
There was a reason for these. Has anything changed? -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ The last time religion ruled, it was called the dark ages.
2015-12-06 11:53 GMT-07:00 Francois Gouget <fgouget(a)free.fr>:
On Fri, 3 Jul 2015, Alex Henrie wrote:
75 characters is the maximum length of a line before gettext breaks it, so this convention will cause each translatable string to fit snugly into the po files. It's also about what we were doing anyway, just not consistently.
I think this patch and particularly its justification does not make any sense.
The command line tool messages were wrapped to the typical width of a terminal: 80 characters. So with this change the messages now take more lines and lose in readability for the user.
Very few translations were actually wrapping at 80 characters. They either wrapped before 80 characters or after, but it was not at all consistent. Most of the line breaks that this patch added were because of lines that were longer than 80 characters anyway. By the way, wrapping at 80 characters instead of at 75 would save all of four lines in cmd.rc and one line in start.rc. You are welcome to submit a patch to make that change.
So now we gettext does not wrap the messages as much in the PO files. But that's totally irrelevant and invisible to the users. It's also totally irrelevant and invisible to a translator as soon as he uses a tool like poedit or a web GUI like Pootle.
So what we have here is a change made solely to make things look a bit nicer to the few developers who look at PO files, at the cost of making them slightly worse for our users. Not a good tradeoff in my book and never a good justification for a patch.
I removed Hebrew "translations" of cmd.rc that were just copies of the English strings,
There was a reason for these. Has anything changed?
What was the reason? It looked like he.po was created by copying en.po and making some edits. There was no reason to continue including outdated English strings in the Hebrew file when Wine automatically falls back to the current English string if there is no Hebrew string. In the rare cases where the string needs to remain untranslated (e.g. "Program Files"), a comment should be added to the translation file (see ca.po for an example). -Alex
On Mon, 7 Dec 2015, Alex Henrie wrote: [...]
Very few translations were actually wrapping at 80 characters. They either wrapped before 80 characters or after, but it was not at all consistent. Most of the line breaks that this patch added were because of lines that were longer than 80 characters anyway.
I don't remember noticing wrapping problems when I looked at the command line tools back in the day. So if you did it so things look nicer on the command line that's ok but that's not the reason what was given in the commit. [...]
I removed Hebrew "translations" of cmd.rc that were just copies of the English strings,
There was a reason for these. Has anything changed?
What was the reason?
See the discussion below with this email stating the Hebrew translator's decision as far as command-line tools are concerned: https://www.winehq.org/pipermail/wine-devel/2011-August/091771.html If you could please fix the Hebrew translation... -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Linux: It is now safe to turn on your computer.
2015-12-07 4:56 GMT-07:00 Francois Gouget <fgouget(a)free.fr>:
I removed Hebrew "translations" of cmd.rc that were just copies of the English strings,
There was a reason for these. Has anything changed?
What was the reason?
See the discussion below with this email stating the Hebrew translator's decision as far as command-line tools are concerned: https://www.winehq.org/pipermail/wine-devel/2011-August/091771.html
Thanks for the link, it was very enlightening. I think the real question is: Are we going to support complex scripts in wineconsole (Hebrew, Arabic, Hindi, Thai), even though Windows does not? If the answer is "yes" then removing the copied English from he.po was the right thing to do, to make room for real translations in the future. If the answer is "no" then we should delete the existing Arabic command translations and replace them with English too. -Alex
On Mon, 7 Dec 2015, Alex Henrie wrote:
2015-12-07 4:56 GMT-07:00 Francois Gouget <fgouget(a)free.fr>:
I removed Hebrew "translations" of cmd.rc that were just copies of the English strings,
There was a reason for these. Has anything changed?
What was the reason?
See the discussion below with this email stating the Hebrew translator's decision as far as command-line tools are concerned: https://www.winehq.org/pipermail/wine-devel/2011-August/091771.html
Thanks for the link, it was very enlightening. I think the real question is: Are we going to support complex scripts in wineconsole (Hebrew, Arabic, Hindi, Thai), even though Windows does not?
Bug 28193 was las tconfirmed in June and while it's totally possible someone added RTL support to wineconsole without me noticing since then it seems unlikely. Similarly the situation of the various Unix terminal emulators probably did not change. So I suspect the answer is not any time soon, and most likely not in 1.8.
If the answer is "yes" then removing the copied English from he.po was the right thing to do, to make room for real translations in the future. If the answer is "no" then we should delete the existing Arabic command translations and replace them with English too.
Removing the corresponding Arabic translation would probably make sense and at least be consistent but it would be more correct to discuss it with the translator first... -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Research is the transformation of money to knowledge. Innovation is the transformation of knowledge to money. -- Dr. Hans Meixner
2015-12-08 4:30 GMT-07:00 Francois Gouget <fgouget(a)free.fr>:
On Mon, 7 Dec 2015, Alex Henrie wrote:
2015-12-07 4:56 GMT-07:00 Francois Gouget <fgouget(a)free.fr>:
I removed Hebrew "translations" of cmd.rc that were just copies of the English strings,
There was a reason for these. Has anything changed?
What was the reason?
See the discussion below with this email stating the Hebrew translator's decision as far as command-line tools are concerned: https://www.winehq.org/pipermail/wine-devel/2011-August/091771.html
Thanks for the link, it was very enlightening. I think the real question is: Are we going to support complex scripts in wineconsole (Hebrew, Arabic, Hindi, Thai), even though Windows does not?
Bug 28193 was las tconfirmed in June and while it's totally possible someone added RTL support to wineconsole without me noticing since then it seems unlikely. Similarly the situation of the various Unix terminal emulators probably did not change. So I suspect the answer is not any time soon, and most likely not in 1.8.
I emailed Microsoft about complex scripts in the Command Prompt, and received the following reply from Yosef Durr: "We are tracking this issue and I don’t have an update at this time." I assume that this means Microsoft considers lack of complex script support to be a bug and they plan to fix it in a future version of Windows. So, there is no reason for us not to fully support these languages in Wine. We might even get it working before Microsoft does ;-)
If the answer is "yes" then removing the copied English from he.po was the right thing to do, to make room for real translations in the future. If the answer is "no" then we should delete the existing Arabic command translations and replace them with English too.
Removing the corresponding Arabic translation would probably make sense and at least be consistent but it would be more correct to discuss it with the translator first...
I am CC'ing Mosaab Alzoubi, the Arabic translation's author. -Alex
participants (2)
-
Alex Henrie -
Francois Gouget