On Tue, Aug 23, 2011 at 12:43 PM, Francois Gouget fgouget@free.fr wrote:
Did you really mean not to CC wine-devel?
Right sorry...
On Tue, 23 Aug 2011, Yaron Shahrabani wrote:
On Mon, Aug 22, 2011 at 3:25 PM, Francois Gouget fgouget@free.fr wrote:
#: crypt32.rc:182 msgid "KeyID=" -msgstr "" +msgstr "KeyID="
I think you should really translate 'KeyID' In French it was translated to 'ID de clé'. So assuming there is a Hebrew word for 'key' then this would not remain as is.
This appears in a certificate, it is much more useful to the user than the Hebrew tern (מזהה מפתח)...
It's in a resource file which usually means the author (Juan Lang in this case) expects it to be translated. If it's not meant to be translated then it should either be removed from the resource file or marked as not needing translation (I have a patch for that, maybe I'll send it tomorrow).
I'm not translating so things will be translated, I also have to make sure that the user experience is somewhat natural and pleasing, translating this string is mostly confusing.
-"\t/i {package|productcode} [property]\n" -"\t/package {package|productcode} [property]\n" +"\t/i {package|product_code} [property]\n" +"\t/package {package|product_code} [property]\n"
Ideally you should translate the user-replaceable strings like 'package' and 'productcode'. But option names such as '/package' should remain as is of course.
Since we have certain RTL issues with the Linux kernel (Hebrew is displayed in reverse) we discourage the translators to translate strings that would probably appear there
msgid "DirectX Diagnostic Tool" -msgstr "" +msgstr "DirectX Diagnostic Tool"
This is sort of a product name os it's always a bit dicey. Still, wouldn't it be better if 'Diagnostic Tool' was translated? At non-English speakers would understand what the purpose of the tool it.
Wasn't quite sure if it appears in a console or GUI, can you tell?
It is displayed in a message box (so GUI).
Great, I will fix this in my next commit, for now it is perfectly fine...
Since we have certain RTL issues with the Linux kernel (Hebrew is displayed in reverse) we discourage the translators to translate strings that would probably appear there
How does the Linux kernel get involved? Using Wine on the Linux console would be quite unusual. Usually it is run in a Gnome terminal, and Xterm or some other GUI equivalent. Don't these do their own handling of text independently from the Linux kernel?
Most terminal emulators doesn't support RTL besides MLTerm. Wineconsole does not support Hebrew or Arabic script out of the box, there are several fonts that should be installed in order to enable that, AFAIK Arabic displayed in the right order but the letters are not joined, I can check that and get back to you.
[...]
-msgstr "%s : File Not Found\n" +msgstr "%s: File Not Found\n"
[...a lot more...]
These are not translated and do not have their place in a PO file. They will prevent future translators working on this file from knowing what has been translated.
They better not work on this... I need this to remain untranslated until the Hebrew bugs in the Linux kernel will be fixed.
In that case you should add translator comments indicating that the string should remain untranslated for the time being. A translator comment is a '#' followed by a space, but adding a second space so it lines up with the others makes it nicer. For instance:
# DO NOT TRANSLATE: needs RTL fixes to the Linux kernel #: cmd.rc:280 msgid "%s: File Not Found\n" msgstr ""
The translator comments will be preserved through the updates.
I'm translating using Virtaal, meaning I can't add comments while translating and I guess other translators as well, I look at comments but sometimes when I have many strings to translate I don't have much time to stop and read each and every one of them, it takes a lot of my (precious) time so for the sake of efficiency I let myself ignore some of them, so do other Hebrew translators, But most of us do understand that if a string is copied as-is it shouldn't be translated (Sort of convention if you like).
It may seem odd but Hebrew, although a private case of Arabic is still not handled the best way it should in computing, there are still many nasty bugs so we do our best to give the Hebrew user the best experience but its still not perfect as we want it to be and we value the efforts of the developers that do help us but we understand if they have no interest and it is fine by us besides I realize there are much more important things to develop so we just leave it aside and deal with what we can deal with our given tools.
Kind regards, Yaron Shahrabani.
-- Francois Gouget fgouget@free.fr http://fgouget.free.fr/ Linux: Because rebooting is for adding new hardware
On Tue, 23 Aug 2011, Yaron Shahrabani wrote: [...]
On Tue, 23 Aug 2011, Yaron Shahrabani wrote:
On Mon, Aug 22, 2011 at 3:25 PM, Francois Gouget fgouget@free.fr wrote:
#: crypt32.rc:182 msgid "KeyID=" -msgstr "" +msgstr "KeyID="
I think you should really translate 'KeyID' In French it was translated to 'ID de clé'. So assuming there is a Hebrew word for 'key' then this would not remain as is.
This appears in a certificate, it is much more useful to the user than the Hebrew tern (מזהה מפתח)...
It's in a resource file which usually means the author (Juan Lang in this case) expects it to be translated. If it's not meant to be translated then it should either be removed from the resource file or marked as not needing translation (I have a patch for that, maybe I'll send it tomorrow).
I'm not translating so things will be translated, I also have to make sure that the user experience is somewhat natural and pleasing, translating this string is mostly confusing.
Juan, what's your take on this. I initially thought that this was essentially part of the same set as 'Surname', 'Organizational Unit', 'State or Province', etc for which it's clear that translation is needed. But apparently 'KeyID=' and the others next to it ('Certificate Issuer', 'Certificate Serial Number=', etc.) are used in a slightly different context. Should they not be translated?
How can one test this in practice?
On Tue, 23 Aug 2011, Yaron Shahrabani wrote: [...]
Since we have certain RTL issues with the Linux kernel (Hebrew is displayed in reverse) we discourage the translators to translate strings that would probably appear there
How does the Linux kernel get involved? Using Wine on the Linux console would be quite unusual. Usually it is run in a Gnome terminal, and Xterm or some other GUI equivalent. Don't these do their own handling of text independently from the Linux kernel?
Most terminal emulators doesn't support RTL besides MLTerm.
Ok, that makes more sense.
Wineconsole does not support Hebrew or Arabic script out of the box, there are several fonts that should be installed in order to enable that, AFAIK Arabic displayed in the right order but the letters are not joined, I can check that and get back to you.
Is there a bug report for this? (I did not see one in a cursory search)
[...]
The translator comments will be preserved through the updates.
I'm translating using Virtaal, meaning I can't add comments while translating and I guess other translators as well,
It looks like Virtaal needs fixing then. I did not find where one can report bugs against it so I don't know if this issue is already known to its developpers. In the meantime I find that emacs (with or without a special editing more) is nice for editing PO files but I don't know how well it works with RTL languages.
I look at comments but sometimes when I have many strings to translate I don't have much time to stop and read each and every one of them, it takes a lot of my (precious) time so for the sake of efficiency I let myself ignore some of them, so do other Hebrew translators,
Well, for Wine it must be quick since it does not have any translator or developper comment so far<g>.
On Tue, Aug 23, 2011 at 4:38 PM, Francois Gouget fgouget@free.fr wrote:
On Tue, 23 Aug 2011, Yaron Shahrabani wrote: [...]
Wineconsole does not support Hebrew or Arabic script out of the box, there are several fonts that should be installed in order to enable that, AFAIK Arabic displayed in the right order but the letters are not joined, I can check that and get back to you.
Is there a bug report for this? (I did not see one in a cursory search)
Paul Vriens helped me with this one, and if I remember correctly he also opened a bug...
[...]
It looks like Virtaal needs fixing then. I did not find where one can report bugs against it so I don't know if this issue is already known to its developpers. In the meantime I find that emacs (with or without a special editing more) is nice for editing PO files but I don't know how well it works with RTL languages.
Just like wine they have bigger issues to deal with thus they are not adding any new dialogs until all the trivial bugs are fixed (In the previous version it took more than a minute to load, Poedit takes about 4-5 seconds).
When you want to use TM tools and make sure you enrich your TM cache while translating, you better not use apps such as emacs, I translate many apps, translating the same sentence over and over again is a complete waste of time. So I get all my former translations as suggestions (Alongside TM suggestions from Google Translator, Microsoft Translator and Open-Tran.eu), this procedure helps me to get into proportion when translating and looking at the same term from different angles, its like having someone proofreading your work while working although using a human proofreader which have different views than you do can definitely improve the translation quality.
I look at comments but sometimes when I have many strings to translate I don't have much time to stop and read each and every one of them, it takes a lot of my (precious) time so for the sake of efficiency I let myself ignore some of them, so do other Hebrew translators,
Well, for Wine it must be quick since it does not have any translator or developper comment so far<g>.
I was not talking about wine, its becoming a habit, when you translate a large amount of apps you look at the comments only if you think that the current translation might be misleading to the user, unfortunately I can't make all the developers add comments whether the string is displayed in CLI/GUI or both and frankly it could be nice but it doesn't worth all the efforts, sometimes I prefer digging into the app and trying to look at the general idea of it myself and then translate, sometimes I skip because this is a real time consumer...
Just like developers have their own tips and tricks, so do translators, sadly not all of them but the tools are gradually improving yet still nothing can replace a professional human translator.
Hope I made things straight. Kind regards, Yaron Shahrabani.
-- Francois Gouget fgouget@free.fr http://fgouget.free.fr/ "Only wimps use tape backup: _real_ men just upload their important stuff on ftp, and let the rest of the world mirror it ;)" -- Linus Torvalds
On Tue, 23 Aug 2011, Yaron Shahrabani wrote:
On Tue, Aug 23, 2011 at 4:38 PM, Francois Gouget fgouget@free.fr wrote:
On Tue, 23 Aug 2011, Yaron Shahrabani wrote: [...]
Wineconsole does not support Hebrew or Arabic script out of the box, there are several fonts that should be installed in order to enable that,
That the user does not have the right fonts installed is not a good enough reason to not translate Wine. However if the Gnome Terminal finds the right fonts and not wineconsole (which seems to be the case incidentally), then that would be a factor.
AFAIK Arabic displayed in the right order but the letters are not joined, I can check that and get back to you.
Is there a bug report for this? (I did not see one in a cursory search)
Paul Vriens helped me with this one, and if I remember correctly he also opened a bug...
I did not see any bug regarding this. So I did some tests, reproduced the problem in Gnome Terminal 3.0.1, xterm 271 and current wineconsole and created a bug:
* Bug 28193 - wineconsole does not support RTL locales http://bugs.winehq.org/show_bug.cgi?id=28193
You should CC-yourself on that bug as the developpers working on it will likely want to check with you when they make progress.
On the translation side I still think that copying untranslated strings over is wrong and I offer to add translator comments instead for the strings of the command line tools. However I would do just do this as an initial pass to ease the transition and you'd then have to live with it.
And since you're the one working with the translation, if you prefer to copy the strings over just say the word. Alexandre will revert my patch and I will not try to get it applied again.
Yaron Shahrabani
<Hebrew translator>
On Fri, Aug 26, 2011 at 4:14 PM, Francois Gouget fgouget@free.fr wrote:
On Tue, 23 Aug 2011, Yaron Shahrabani wrote:
On Tue, Aug 23, 2011 at 4:38 PM, Francois Gouget fgouget@free.fr wrote:
On Tue, 23 Aug 2011, Yaron Shahrabani wrote: [...]
Wineconsole does not support Hebrew or Arabic script out of the box, there are several fonts that should be installed in order to enable that,
That the user does not have the right fonts installed is not a good enough reason to not translate Wine. However if the Gnome Terminal finds the right fonts and not wineconsole (which seems to be the case incidentally), then that would be a factor.
The thing is that console strings might also appear in terminals (gnome-terminal for example when you load a wine app through it) so fixing wineconsole might just not do the work so even after this bug is solved I can't translate CLI apps not to mention that the strings will still appear in the wrong direction after they are already translated.
It might sound weird but the Israeli community really doesn't care about this terminal bug, whoever wants to work with Hebrew in terminal can simply use MLTerm or Konsole, Arabeyes was once concerned about this and they developed BiCon, Nice project indeed but it was neglected few years ago due to lack of interest, I can guess for the exact same reason.
AFAIK Arabic displayed in the right order but the letters are not joined, I can check that and get back to you.
Is there a bug report for this? (I did not see one in a cursory search)
Paul Vriens helped me with this one, and if I remember correctly he also opened a bug...
I did not see any bug regarding this. So I did some tests, reproduced the problem in Gnome Terminal 3.0.1, xterm 271 and current wineconsole and created a bug:
* Bug 28193 - wineconsole does not support RTL locales http://bugs.winehq.org/show_bug.cgi?id=28193
You should CC-yourself on that bug as the developpers working on it will likely want to check with you when they make progress.
Done, thanks for the report!
On the translation side I still think that copying untranslated strings over is wrong and I offer to add translator comments instead for the strings of the command line tools. However I would do just do this as an initial pass to ease the transition and you'd then have to live with it.
And since you're the one working with the translation, if you prefer to copy the strings over just say the word. Alexandre will revert my patch and I will not try to get it applied again.
I did dome changes and resubmitted, things will be better this time.
Since I am currently the only translator I want to make things clear to my successor... I'm just bringing my conventions from GNOME in here... Wine and GNOME are both translated using the same rules and methods leaving no translation gaps between these two (in Hebrew).
I do understand what you are saying but this is actually necessary...
-- Francois Gouget fgouget@free.fr http://fgouget.free.fr/ La terre est une bêta...
On Sat, Aug 27, 2011 at 5:32 PM, Shachar Shemesh shachar@shemesh.biz wrote:
On 08/26/2011 04:35 PM, Yaron Shahrabani wrote:
It might sound weird but the Israeli community really doesn't care about this terminal bug
AFAIK, the Windows console does not do BiDi either (which would mean that, in order to be bug compatible with Windows, neither should wineconsole). To be fair, it has been quite a while since I last checked, so something may have budged on that front.
Well... you can look at it that way, technically speaking you are absolutely correct but since there is a fix that allows displaying and working with Hebrew in terminal this decision is simply kicking in the user's face.
Microsoft had this decision in Windows XP, many DOS apps that were supported until Windows 98 were no longer supported and had to search for alternative or keep using an unsupported operating system. This move eventually forced most of these businesses to go with the flow and pay thousands of dollars to upgrade their software after they already spent thousands of dollars few years prior to the release of XP.
Supporting forced end-of-life of a product? Seems very Microsoftish ☺
The greater problem is that BiDi console is an unsolvable problem. I have not played much with MLTerm, but with Konsole, I keep it as a handy "turn on, look, turn off" feature. Without a good semantic understanding of the string it is almost impossible to perform BiDi reordering, and the results vary from barely readable to undecipherable.
The reason MLTerm is not widely used that it doesn't support themes which makes the window look very ugly and not so friendly. But MLTerm definitely works better than Konsole, If you have the time to take a look at it you'll be surprised (Ignore the window decorations of course).
What I'm saying is that unlike Microsoft which had its own political reasons to cease their Hebrew support in console wine should support it. There is a way of using Hebrew in console, the fix is described in this URL: http://eesh.net/WinHeb/
Works in Vista as well, doesn't work in Win7 though...
Kind regards, Yaron Shahrabani.
Shachar
-- Shachar Shemesh Lingnu Open Source Consulting Ltd. http://www.lingnu.com
On Sat, 27 Aug 2011, Yaron Shahrabani wrote: [...]
Microsoft had this decision in Windows XP, many DOS apps that were supported until Windows 98 were no longer supported and had to search for alternative or keep using an unsupported operating system.
I did some tests in Windows 7. cmd, ipconfig and net are translated to French but not to Russian (LTR), Japanese (LTR) or Hebrew (RTL). So I don't know if it would support the output of RTL strings from console applications such as usage or error messages. If anyone knows of an application I could test.
In all cases the prompt is LTR (the path itself being an LTR string anyway: c:\Users...).
On Sun, 28 Aug 2011, Shachar Shemesh wrote: [...]
Yes. It's called "type". Take a Hebrew text stored in a Windows 1255 encoded file, and "type file", see what happens. The order, if I understand this correctly, will be logical.
The Windows 7 console does not even support displaying the Hebrew characters. My understanding is that this is because the only fonts it lets you pick are lacking the required characters.
I tested this by creating a Unicode file with notepad (which displayed everything fine, in Windows 7), containing:
--- Hello שלום ---
The first line was ok but the second one was either question marks or squares. The only fonts Windows will let me pick are 'Consolas', 'Lucida Console' and 'Raster Fonts'.
On Mon, 29 Aug 2011, Shachar Shemesh wrote: [...]
Yes, it does not support Unicode. That's why I said "1255", as in "Windows 1255", the ANSI encoding for Hebrew.
It does support Unicode (UTF-16) otherwise 'Hello' would have not been displayed correctly. Furthermore I also tested with a Windows 1255 encoded and did not have any luck with it either.
The first line was ok but the second one was either question marks or squares. The only fonts Windows will let me pick are 'Consolas', 'Lucida Console' and 'Raster Fonts'.
It should let you pick any monospace font. At least one of those should contain a Hebrew encoding. If not, you might need to set the default locale to Hebrew in order to test this (which will only be possible after clicking "add support for complex text layout languages", or something to similar effect, in Regional Settings). This will also install the Hebrew fonts.
I am only given the three font choices I listed. Also I did test this in a Hebrew locale. I did not have to check an 'add support for complex text layout languages' option however. All I did was go to the Windows Update site and select the Hebrew support option.
On Fri, Aug 26, 2011 at 15:14, Francois Gouget fgouget@free.fr wrote:
On Tue, 23 Aug 2011, Yaron Shahrabani wrote: ... On the translation side I still think that copying untranslated strings over is wrong <...>
Actually, for standardization, empty msgstr should also be marked with ", fuzzy" IMHO.
Frédéric
On Sat, 27 Aug 2011, Frédéric Delanoy wrote:
On Fri, Aug 26, 2011 at 15:14, Francois Gouget fgouget@free.fr wrote:
On Tue, 23 Aug 2011, Yaron Shahrabani wrote: ... On the translation side I still think that copying untranslated strings over is wrong <...>
Actually, for standardization, empty msgstr should also be marked with ", fuzzy" IMHO.
Why?
An empty msgstr is unambiguously untranslated. Also I would define the standard by what the gettext tools do and when they generate a new po file they don't mark all empty msgstrs as fuzzy.
If the problem is that you have trouble finding untranslated messages in a text editor, then that's one point where having a dedicated PO editor helps (or emacs' PO mode).
2011/8/27 Francois Gouget fgouget@free.fr:
On Sat, 27 Aug 2011, Frédéric Delanoy wrote:
On Fri, Aug 26, 2011 at 15:14, Francois Gouget fgouget@free.fr wrote:
On Tue, 23 Aug 2011, Yaron Shahrabani wrote: ... On the translation side I still think that copying untranslated strings over is wrong <...>
Actually, for standardization, empty msgstr should also be marked with ", fuzzy" IMHO.
Why?
An empty msgstr is unambiguously untranslated. Also I would define the standard by what the gettext tools do and when they generate a new po file they don't mark all empty msgstrs as fuzzy.
OK didn't know that
If the problem is that you have trouble finding untranslated messages in a text editor, then that's one point where having a dedicated PO editor helps (or emacs' PO mode).
Not really a problem, it's just easier to find when you can have translated multiline msgstr like msgid "some long text" msgstr "" "some very long" "translation"
(I have to use relatively complex regexp to find those cases).
To remain consistent with the gettext tools, for multiline translation, the generated po entry should be IMO sthg like msgid "some long text" msgstr "some very " "long translation"
i.e. the start of the translation remains on the same line as 'msgstr'
Frédéric
On Sat, 27 Aug 2011, Frédéric Delanoy wrote: [...]
If the problem is that you have trouble finding untranslated messages in a text editor, then that's one point where having a dedicated PO editor helps (or emacs' PO mode).
Not really a problem, it's just easier to find when you can have translated multiline msgstr like msgid "some long text" msgstr "" "some very long" "translation"
(I have to use relatively complex regexp to find those cases).
Again this won't be a problem if you a PO tool for edition or use Emacs' PO mode.
To remain consistent with the gettext tools, for multiline translation, the generated po entry should be IMO sthg like msgid "some long text" msgstr "some very " "long translation"
Again this is not what the PO tools do and it is them that format the PO file when Alexandre updates them. Besides for long messages the msgid string starts on the next line so the msgstr should do the same. You could complain about this to the gettext authors though (I just doubt they would change it).
On 8/23/11 8:38 AM, Francois Gouget wrote: [...]
Wineconsole does not support Hebrew or Arabic script out of the box, there are several fonts that should be installed in order to enable that, AFAIK Arabic displayed in the right order but the letters are not joined, I can check that and get back to you.
Is there a bug report for this? (I did not see one in a cursory search)
If a bug is made/found I would be very interested in being CC'ed on that. Doing the RTL work in WINE is something I am very much enjoying.
-aric
-
Aric Stewart -
Francois Gouget -
Frédéric Delanoy -
Shachar Shemesh -
Yaron Shahrabani