If you are Persian, you may not always want to follow your Parent

by Michael S. Kaplan, published on 2010/09/20 07:01 -04:00, original URI: http://blogs.msdn.com/b/michkap/archive/2010/09/20/10064640.aspx

This blog is not making any kind of political statement about Iranian President Mahmoud Ahmadinejad or anyone else from Iran. It is about the Persian Language Interface Pack. Oh and the Pashto one. And the Urdu one. And the Dari one....

I've been using (and loving) the LIPs since Windows XP. They are really useful for getting people who haven't mastered English yet to still be connected to the world (like my grandmother). So kudos to Microsoft. Now, there is one problem and that is Microsoft's refusal to ship a native PDF reader app with Windows (I understand there may be antitrust issues here, but still). That leaves users to have to go for third-party tools like Adobe or Foxit. The problem is that Adobe doesn't seem to care too much about Farsi users and doesn't offer any language assistance to Farsi speakers. Foxit doesn't have any support either (although I'm in the process of creating a translation). The only useable alternative is SummatraPDF. Now I've been helping the developer of SummatraPDF with the translation into Farsi (which was started and substantially completed by another user). However, we are having a bit of problem trying to figure out how we can get the program to follow the LTR settings of the underlying Windows. A lot of applications seem to have no problem with this and switch the window controls and menus around once the LIP is installed. We are trying to do the same thing with SummatraPDF. I realize this might not be your area, but I was hoping you would be able to at least point us in the right direction. This way we can at least provide an alternative PDF reader for Farsi speakers until (fingers-crossed) Microsoft comes out with a PDF application for Windows (and includes the language files in the LIP).

Again thanks for your efforts.

Bests,
Still

I am not a lawyer, but I am unaware of any specific antitrust issue related to PDF reading or writing. Since it is not my background, I won't comment further on that except to say that after all the words I have said recently about PDF quality with complex scripts that even arguably the ultimate PDF tool (Adobe Acrobat) has, I imagine I would be VERY hard on quality issues for anyone who tried to jump into that foray on the platform side -- for either reading or writing. The world doesn't need yet another application doing it wrong....

With that said, i wanted to talk about what the bulk of the comment was about, since that is an area I know something about.

The rest of the comment is referring to a very interesting issue that affects many different Windows Language Interface Packs -- not just the Persian one, but also the Pashto one from prior versions, and the Urdu and Dari ones from Windows 7 and prior versions as well.

Now if one does not use the myriad of ways to explicitly set the directionality of the process, then the process directionality is inherited from its parent.

The vast majority of processes that users directly deal with do not set directionality explicitly. And they tend to have Windows Explorer as their parent launching process.

You see, when one is on Arabic or Hebrew, one's "parent" has an RTL directionality (Arabic or Hebrew, respectively), but in the case of LIPs, they are all installed atop English, which means that even though the user interface language is Persian (or Urdu or Pashto or Dari), there is an underlying LeftToRight-ness of any process one creates while running on this configuration that does not explicitly try to be something else.

In the case of SummatraPDF, it appears to be [incorrectly] assuming that the RightToLeft-ness of the localized pieces of the Persian LIP are getting their directionality from a parent inheritance type thing, when they are actually getting it from a couple of LRMs in the FileDescription property of the .mui files attached to the EXE of the process (I doubt SummatraPDF is using .mui files; in their case they just need the localized file to either insert the two LRMs or use one of the many other methods such as a

Now this solution is not perfect, but since there is so much of the user interface that is not "top-level" and thus not localized in a LIP, changing the design would essentially break the directionality of many pieces of the existing user interface since so much of it does currently rely on the inheritance from a parent, and no one wants to start tagging everything with some kind of new "use LTR" tag to update all of the UI in Windows.

I think what the user meant considering anti-trust issues is that if Microsoft boundled a PDF reader with Windows, the same as with IE and the browserchoice update could happen in the EU.

But then again, Microsoft could be also boundling Flash, Shockwave, and what else all.

I don't understand why Persian UI for an application should depend on the LIP being installed. There are quite a few applications on the Isralei market that feature full localized (Hebrew RTL) UI even when they are used on English version of Windows (or if English UI language is chosen for the Hebrew version, which is esentially the same, to the best of my knowledge).

It's true that some features must be taken care of carefully. For example, the system message box cannot be used as is.

If I understand Still's situation correctly, he was choosing the UI language for a PDF reader (Foxit or SummatraPDF) based on the user's choice for the system. It could be a reasonable first guess - if Windows displays its UI in Farsi, use Farsi UI (RTL). If Windows displays in English, or French - use an LTR UI.

Such approach is, IMHO, flawed. It's OK for certain applicateion to be "more user friendly" than the system. I.e., to have PDF reader with Farsi RTL UI while all system applications, like Windows Explorer, use English menus and buttons and layout. Which is the case of a system without LIP installed.

Now, LIP does make the things easier: you can launch a MessageBox and it will know how to display لغو and خوب. As you explained, you cannot inherit RTL-ness from the parent, that's all. But going an extra mile and providing built-in message boxes and dialogs may be justified for many languages.

Not exactly. The issue was hoping to have it help, and unhappy that it did not. So I explained how to be independent of that, and why even when it might be expected to have helped, it won't (since the question was about why didn't it).

In other words, everything I answered does what you are suggesting, though you seem to be suggesting it does something else? :-)