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...
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.
Great, I will fix this in my next commit, for now it is perfectly fine...
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.
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.
On Tue, 23 Aug 2011, Yaron Shahrabani wrote: [...]
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: [...]
Ok, that makes more sense.
Is there a bug report for this? (I did not see one in a cursory search)
[...]
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.
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:
Paul Vriens helped me with this one, and if I remember correctly he also opened a bug...
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 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.
On Tue, 23 Aug 2011, Yaron Shahrabani wrote:
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.
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:
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.
Done, thanks for the report!
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...
On Sat, Aug 27, 2011 at 5:32 PM, Shachar Shemesh shachar@shemesh.biz wrote:
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 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.
On Sat, 27 Aug 2011, Yaron Shahrabani wrote: [...]
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.
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:
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:
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:
OK didn't know that
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: [...]
Again this won't be a problem if you a PO tool for edition or use Emacs' PO mode.
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: [...]
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