> Roland Mainz wrote at 07/11/06 14:35:
> > Mike Kupfer wrote:
> >>>>* usr/src/cmd/ksh/Makefile
> >>>> - where are we with i18n? will we have a real ksh93.po prior to
> >>>> putback?
> >>
> >>Roland> I think you're asking here about l10n (=localisation), right ?
> >>
> >>Well, i18n and l10n both. I hadn't realized that the i18n issues had
> >>been addressed, so I assumed that the l10n stuff was turned off because
> >>we were waiting for the i18n fixes.
> >
> >
> > Both i18n and l10n support is compiled in the ksh93 binaries. It's just
> > that we miss the files which contain the translated text...
> >
> >
> >>Roland> Localisation (AFAIK the *.po stuff is for l10n) is working in
> >>Roland> the ksh93 binaries - but I simply didn't investigate the details
> >>Roland> including:
> >>Roland> - Where are the localisation files used for the different
> >>Roland> locales stored
> >>
> >>The way it works is each consolidation delivers a single messages
> >>package to the globalization (g10n) group. The g10n group is
> >>responsible for the translations. I assume that either the g10n group
> >>or Release Engineering creates the l10n files/packages that get
> >>installed. The package that ON delivers to g10n is SUNW0on (it's
> >>defined in usr/src/pkgdefs, though I don't think it's part of the
> >>standard build).
> >
> >
> > Umpf... we can't stuff the l10n files for ksh93 into the OS/Net tree ? A
> > seperate, non-public repository for such content isn't very usefull (for
> > non-Sun people...) ;-(
> >
> >
> >>Roland> how can we keep track of changes (syncronisation issue) ?
> >>
> >>I'm not entirely sure how this is managed currently. Entries in the bug
> >>database do have a radio button "does this change affect localization
> >>yes/no", but I don't know how that information gets back to the g10n
> >>group, or if they even use it. This is probably a good question for
> >>Ienup or for the i18n-discuss list.
> >
> >
> > Ok... adding Ienup Sung <Ienup.Sung at Sun.COM> to the CC:-list... :-)
>
> Thanks for cc'ng me.
>
> When ON group at Sun builds SunOS, the build includes SUNW0on package that
> contains all localizable files. And then the SUNW0on package gets delivered
> along with all other packages and G11N group will pick it up and do
> translation and deliver MO files and so on localized files into Solaris
> usually at the next or so build(s) as French, Italian, German, Spanish,
> Swedish, Chinese, Japanese, Korean, and so on localization packages.
>
> I don't think we have set up anything similar in OSo yet in terms of such
> process. I cc'd Young J. Song who is the PM responsible for the OSo G11N
> and working on the process in my understanding. She might have already done
> some work on that front. I also cc'd i18n-discuss mailing list.
>
> I also think that keeping localized files at G11N source tree would make
> much sense since we keep substantial amount of tranlsation memory that we can
> utilize and also all localization expertises are reside within G11N group.
> (Furthermore, it would be kind of waste of time and lots of redundancy if
> each and every individual project, community and so on will deal with
> localization, localization packages and so on by itself when you can just
> drop off your localizable files to G11N community where G11N people will
> take care of all the L10N details for your components/projects/communities.)
>
> We also have alredy open sourced localized files for ON and so any one who
> is interested can participate and localize for their languages/locales. And
> more will come once other consolidations/communities are open up their
> source code:
>
> http://www.opensolaris.org/os/community/int_localization/sources/
>
> Ienup
>
The AST Toolkit has nmake rules for generating the C locale file
containing all the translation phrases that need to be localized
for each command or library. The file that gets generated
contains both error message strings and built-in man page
strings. It generates a list of numbers and strings.
The source code does not use gettext(). Phrases needing translation
are generated by the AST msgcc command which produces the C locale
version of the message file.
When given the previous C locale file, the message numbers will
be used for phrases that have not changed and new numbers for
new and changes messages.
For each locale, the user must generate files with the same
set of message number but with the phrases in the current locale.
The AST toolkit provides commands for converting from the binary
format for locale files into a textual format that can be
used for editing. The binary format uses UTF-8 format for
the messages.
For more information go to
http://www.research.att.com/sw/download/
and click on internationalization and look at the man pages
for msgcc, msggen, and msgget.
David Korn
dgk at research.att.com
