🚀 go-pugleaf

PMC e-mail id: 1064

>After reading the annoucement about products being released that do translation
>and not localization of text I am confussed. I have read several articles and
>papers about translating in software instead of localizing manually and was
>comfortable with the position that it was not practical to use that approach.
>Is there anyone out there that can provide more insight into this approach? We
>looked into translating phrases based on pattern match but gave it up due to the
>number of minor variations that were required for all the text. Basically, it
>took a lot of memory to hold all the possible Latin-1 and Kanji text. Is there
>a better way to do this? Is table driven approachs the only way or are there
>translation algorithms?

>From my own experience of helping localization, aside from a very
small simple program, table driven approach seems to be the only way.
There is no usable translation algorithm as far as I know which works
all the time.

Also, the simple string entry is NOT enough. Occasionally, you need to
attach context (eg, from which routine the string is referenced.).

Eg: Suppose in your application there are menus that contain
the word "open" in the following two meanings.

	open ... as in opening a file (open used as verb), and
	open ... to show the status of a file being open (open used as
		 adjective).

In translating the two menu items, we have to come up with two
DIFFERENT Japanese translations. Hence the table entries need to
have additional information to resolve these confusing cases.
Simple way to do is to assign unique numbers to each items of every
menu in the software, and tag the table entry with such number.

Regarding step-by-step guide to i18n, I would love to hear if such
guide exists. I have been trying or rather struggling to learn i18n in
ISO C locale stuff, latest POSIX i18n efforts, and X11R5 i18n functions.
But I am far from obtaining the consistent general overview :-(

I can give two cents worth of my info: i18n is NOT enough. You have a
big problem of applying LOCALIZATION to each different market. There
lies the chance of incompatible localization done by different vendors
who start from the SAME i18N software!  Lack of standardization is one
reason. But basically, in my humble opinion, the main reason is that
we don't know exactly what i18n and localization should be. It seems
to me that everyone is entitled to his/her opinion at this moment.

For example, the lack of standardization let different Japanese
vendors to use different locale names to be used with X11R5 i18n
software when the software was ported to different vendor's platform.
Changing locale name is not a hard thing to do.
But there are many other things that are not sorted out yet concerning
localization.

------------------------------------------------------------------
    Chiaki Ishikawa                       Phone:+81-3-5702-0351
  Personal Media Corp.                      FAX:+81-3-5702-0359
 MY Bldg, 1-7-7 Hiratsuka,   UUNET: ... uunet!pmcgw!ishikawa, or
 Shinagawa-ku, Tokyo 142                ishikawa%pmcgw@uunet.uu.net, or
        JAPAN               (in Japan)  ishikawa@personal-media.co.jp
------------------------------------------------------------------