[i18n] Horde IMP in Japanese

[Takeshi Morishima]

In message "Re: [i18n] Horde IMP in Japanese" on 2003/08/18, Jan
    Schneider writes:

  > You will still get the translation's original charset instead of
  > UTF-8 if the server system don't know UTF-8 charsets as
  > ja_JP.UTF-8 (like Windows).  In this case the result of system
  > calls would still be in the locale's original charset and we can't
  > determine which strings to convert to UTF-8 and which not. Thus we
  > simply fall back to the original charset (Shift-JIS in the case of
  > Japanese).

Yes, the CVS version works now for me.  (Both charset encoding and
access key issue.)  I see that the encoding selected is entirely Shift
JIS (no longer UTF-8) for my Windows server on all the frames.  Just
curiousity, if the user's browser does not support UTF-8 but Shift JIS
or EUC-JP, does Horde fall back to Shift JIS or EUC-JP, even though
the server can support UTF-8?  (It seems to be yes after looking at a
few source files, but not sure how much control it provides and how to
designate the precedence e.g. use of Shift JIS over EUC-JP, etc...)


  > >     label may.  A better way may be to use gettext processing
  > >     _() after getAccessKey is processed, i.e. use an English
  > >     text for when finding an access key, and get actual
  > >     translated label afterward.  For example, if "Accounts" is
  > >     translated, label is set to "Accounts" for getAccessKey()
  > >     purpose and the access key is determined as "A", then it is
  > >     translated according to locale using _() when sending the
  > >     page back to the user's browser.  (This is major change
  > >     though.)
  > 
  > This would definitely the best solution.

One other hack idea would be to allow translated string to include
designated shortcut key candidates with a special delimiter e.g.
"ACUNT|アカウント" (in this case the delimiter is '|').  Whatever
string upto the delimiter can be deleted after an access key is
extracted, and before the string is displayed.  This way, a language
translator can control access key candidates according to their
language preferences (closer to native pronounciation etc.)  Downside
of this would be some extra processing using up more CPU cycles and
does not seem to be very elegant solution.


  > >   o One last small note, translation.php causes some errors when
  > >   it is invoked in a directory where its directory path contains
  > >   some white spaces.  In my case "c:\Program Files\" in cygwin
  > >   window.
  > 
  > Some of these should be fixed now, but I probably didn't catch
  > all. If you still get some errors, please post the whole command
  > you entered.

Yes.  For now the command I was having the problem seems to be fixed.


Thank you,
Takeshi