[9fans] localization

[9fans] localization

[dexen deVries]

browsing through uriel's slides from fosdem 2006 [1], i see him mention Plan 9 
lacks localization. what are this lists feelings on localization (both 
translation of strings and formatting of numbers, time etc.) of user-facing 
applications?

the only model i know right now is gettext() and related from GNU; there's 
gotta be a better way; perhaps an fs for it? ;-)

[1] http://cm.bell-labs.com/sources/contrib/uriel/slides/fosdem06/slides.pdf
-- 
dexen deVries

[[[↓][→]]]

``In other news, STFU and hack.''
mahmud, in response to Erann Gat's ``How I lost my faith in Lisp''
http://news.ycombinator.com/item?id=2308816

Re: [9fans] localization

[erik quanstrom]

!/bin/upas/marshal -s 'Re: [9fans] localization' -R /mail/fs/mbox/3100 9fans@9fans.net
On Wed Apr 27 12:04:56 EDT 2011, dexen.devries@gmail.com wrote:
> browsing through uriel's slides from fosdem 2006 [1], i see him mention Plan 9
> lacks localization. what are this lists feelings on localization (both
> translation of strings and formatting of numbers, time etc.) of user-facing
> applications?

it's not the implementation that bothers me so much as the
theory of operation.  command-line utilities are localized s.t.
it becomes necessary to fiddle with the locale if you want to
parse the output.  but then you can't present this as localized
output yourself easily.  localization can go as far as changing the set
of digits, or even the default numbering base!  they also don't
choose a character set.  shell scripting becomes impossible.

i realize no localization makes life difficult for folks who speak greek.
it would be interesting to hear from a non-native english speaker
on if they think dealing with the computer in english is something
that can be done once and then forgotten, and if this is less work
than dealing with the tower of locale.

it would be interesting to hear ideas on this.  it's a hard problem.

- erik

Re: [9fans] localization

[Gabriel Diaz]

Hello

We install operating systems in English. Spanish / Catalan localized
systems are a source of problems like:

* error messages do not reflect was going on in Spanish but it does in
English, and in some cases it can mislead the user, jumping to a
wrong conclusion
* translations are often outdated, referring to things not present in
the system anymore
* applications do not always use the localization engine of the
system, so you end with multiple languages and localization
implementations, grep-ing though a localized log file is painfull if
you must deal with more than one language (and can lead you to use
error codes)
* jargon is usually translated and used in strange way at best, also
the 'false friends' words are difficult to handle in an automated way

I would prefer to have a system completely in English but polished,
instead of a badly or half translated system.

"La memoria no se puede 'written'" is a common windows error, which
shows the kind of problems they found.


slds.

gabi

On Wed, Apr 27, 2011 at 6:14 PM, erik quanstrom <quanstro@quanstro.net> wrote:
> !/bin/upas/marshal -s 'Re: [9fans] localization' -R /mail/fs/mbox/3100 9fans@9fans.net
> On Wed Apr 27 12:04:56 EDT 2011, dexen.devries@gmail.com wrote:
>> browsing through uriel's slides from fosdem 2006 [1], i see him mention Plan 9
>> lacks localization. what are this lists feelings on localization (both
>> translation of strings and formatting of numbers, time etc.) of user-facing
>> applications?
>
> it's not the implementation that bothers me so much as the
> theory of operation.  command-line utilities are localized s.t.
> it becomes necessary to fiddle with the locale if you want to
> parse the output.  but then you can't present this as localized
> output yourself easily.  localization can go as far as changing the set
> of digits, or even the default numbering base!  they also don't
> choose a character set.  shell scripting becomes impossible.
>
> i realize no localization makes life difficult for folks who speak greek.
> it would be interesting to hear from a non-native english speaker
> on if they think dealing with the computer in english is something
> that can be done once and then forgotten, and if this is less work
> than dealing with the tower of locale.
>
> it would be interesting to hear ideas on this.  it's a hard problem.
>
> - erik
>
>

Re: [9fans] localization

[Lluís Batlle i Rossell]

On Wed, Apr 27, 2011 at 07:08:27PM +0200, Gabriel Diaz wrote:
> Hello
>
> We install operating systems in English. Spanish / Catalan localized
> systems are a source of problems like:
> ...

Hello,

I think it's easier to find a programmer that wants to fix a program behaviour,
than to find someone willing to do or fix a translation.

And in the world of open source, most of the programming efforts go towards
getting the programs do de job, and then create or fix something else.

Those knowing how to program well are those who can deal with English easily.
Writing with a latin script without diacritics makes the life easier too. Even
the whole old story about 'char' holds a character can go just fine.

It's also easier to deal with fixed-width fonts than with many typing fanciness,
as it is easier to take types as fixed drawings than combine them as in arabic.

I think programmers will often have an opinion biased towards their skills
(knowing English) and their interests (making programs work and then fix the
next).

I particularly enjoy good translations into my language, both in programs,
books, films, or whatever. I find it, translating, a job to be proud of.

> On Wed, Apr 27, 2011 at 6:14 PM, erik quanstrom <quanstro@quanstro.net> wrote:
> > !/bin/upas/marshal -s 'Re: [9fans] localization' -R /mail/fs/mbox/3100 9fans@9fans.net
> > On Wed Apr 27 12:04:56 EDT 2011, dexen.devries@gmail.com wrote:
> >> browsing through uriel's slides from fosdem 2006 [1], i see him mention Plan 9
> >> lacks localization. what are this lists feelings on localization (both
> >> translation of strings and formatting of numbers, time etc.) of user-facing
> >> applications?
> >
> > it's not the implementation that bothers me so much as the
> > theory of operation. �command-line utilities are localized s.t.
> > it becomes necessary to fiddle with the locale if you want to
> > parse the output. �but then you can't present this as localized
> > output yourself easily. �localization can go as far as changing the set
> > of digits, or even the default numbering base! �they also don't
> > choose a character set. �shell scripting becomes impossible.
> >
> > i realize no localization makes life difficult for folks who speak greek.
> > it would be interesting to hear from a non-native english speaker
> > on if they think dealing with the computer in english is something
> > that can be done once and then forgotten, and if this is less work
> > than dealing with the tower of locale.
> >
> > it would be interesting to hear ideas on this. �it's a hard problem.
> >
> > - erik
> >
> >
>

Re: [9fans] localization

[tlaronde]

Hello,

On Wed, Apr 27, 2011 at 05:59:08PM +0200, dexen deVries wrote:
> browsing through uriel's slides from fosdem 2006 [1], i see him mention Plan 9
> lacks localization. what are this lists feelings on localization (both
> translation of strings and formatting of numbers, time etc.) of user-facing
> applications?
>
> the only model i know right now is gettext() and related from GNU; there's
> gotta be a better way; perhaps an fs for it? ;-)

As an example of the joy of the localization, switching recently KerGIS
servers from NetBSD 3.x to NetBSD 5.x, the same code recompiled would
give errors, with cryptic messages, until I happen to pin the problem to
the formating of numbers... I use, as a backup version of files, a text
(mainly ASCII) transcription of the data, and use 'd.d' for example. But
since users had LC_ALL set to french, NetBSD 3.x didn't support nor time
neither number localization so no problem, but 5.x now does. Result :
"french" 'd,d' was expected for input; and 'd,d' sent for output. Joy!

For another mean instead of gettext(), you have what has done Donald E.
Knuth with TeX and al: : all the strings are extracted in a "pool"
file---a text file---, so as long as one sticks to the index (the
position), one can provide a translated pool file to localize.

Furthermore, IMHO, there are 3 levels:

- 0: firmware/kernel: LANG C (a restricted faulty subset of english)
- 1: system libraries and utils, directly used by programmers, not
really users: LANG C (idem)
- 2: user level scripts or programs; since they are adapted for higher
level manipulation, the levels 0 and 1 messages have no meaning for the
user, so it is useless to translate. And since level 2 shall match the
user (here is the business!), this is not a problem.

So, for me at least, the best solution to this difficult problem is the
one provided for Plan9 by Rob Pile and Ken Thompson (I cite the authors
of the "Hello World or...", i.e. UTF8.

More is too much.
--
        Thierry Laronde <tlaronde +AT+ polynum +dot+ com>
                      http://www.kergis.com/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C

Re: [9fans] localization

[erik quanstrom]

> Those knowing how to program well are those who can deal with English easily.
> Writing with a latin script without diacritics makes the life easier too. Even
> the whole old story about 'char' holds a character can go just fine.
>
> It's also easier to deal with fixed-width fonts than with many typing fanciness,
> as it is easier to take types as fixed drawings than combine them as in arabic.

both of these problems are quite easy to solve, since they
can be solved once, and are solved problems in plan 9.

- erik

Re: [9fans] localization

[Lluís Batlle i Rossell]

On Wed, Apr 27, 2011 at 02:17:54PM -0400, erik quanstrom wrote:
> > Those knowing how to program well are those who can deal with English easily.
> > Writing with a latin script without diacritics makes the life easier too. Even
> > the whole old story about 'char' holds a character can go just fine.
> >
> > It's also easier to deal with fixed-width fonts than with many typing fanciness,
> > as it is easier to take types as fixed drawings than combine them as in arabic.
>
> both of these problems are quite easy to solve, since they
> can be solved once, and are solved problems in plan 9.

But then comes the antialiasing, the subpixel rendering for LCDs, the hinting,
and all becomes quite complex. I think plan9 works mostly with bitmap fonts,
isn't it?

I was not aware that plan9 had the arabic linking solved. Good to know!

As for the localisation of software, regarding the implementation to allow
comfortable localisation without much trade-offs, I can't suggest anything of
value now.

Thank you,
Llu�s.

Re: [9fans] localization

[dexen deVries]

On Wednesday 27 of April 2011 22:45:52 Lluís Batlle i Rossell wrote:
> But then comes the antialiasing, the subpixel rendering for LCDs (...)

as a side  note; antialiasing and sub-pixel rendering are moot with decent 
DPIs. for example, IBM T221, which runs at 204DPI -- about 9.2MPix on 22''.


-- 
dexen deVries

``One can't proceed from the informal to the formal by formal means.''

Re: [9fans] localization

[erik quanstrom]

> > > It's also easier to deal with fixed-width fonts than with many typing fanciness,
> > > as it is easier to take types as fixed drawings than combine them as in arabic.
> >
> > both of these problems are quite easy to solve, since they
> > can be solved once, and are solved problems in plan 9.
>
> But then comes the antialiasing, the subpixel rendering for LCDs, the hinting,
> and all becomes quite complex. I think plan9 works mostly with bitmap fonts,
> isn't it?

plan 9 uses bitmap fonts, but bitmap fonts may be subpixel fonts.  i'm using
one right now.

i think you just made a slipperly slope argument.  just because you solve
one problem, doesn't mean you have to solve every related problem.

> I was not aware that plan9 had the arabic linking solved. Good to know!

sorry.  i didn't read carefully enough.  that's not solved.

however, there are some i18n-related problems that are simply solved.
my system has 32-bit runes and full unicode 6.0 tables for things like
isupperrune, etc. all programs are now happy with runes values up to
0x10FFFF.  grep also accepts -I, which by analogy to -i strips everything
down to a base rune, like dict(1) has traditionally done.  russ has pointed
out that converting to character classes would be faster, and it is, but
only by about 30%.

the first order problem right now is variable-height lines of text so, e.g.,
Ñ doesn't look so bad.

- erik

http://www.quanstro.net/magic/man2html/1/grep
http://www.quanstro.net/magic/man2html/2/isalpharune
http://www.quanstro.net/magic/man2html/2/runeclass

Re: [9fans] localization

[Iruatã Souza]

On Wed, Apr 27, 2011 at 3:04 PM,  <tlaronde@polynum.com> wrote:
> Hello,
>
> On Wed, Apr 27, 2011 at 05:59:08PM +0200, dexen deVries wrote:
>> browsing through uriel's slides from fosdem 2006 [1], i see him mention Plan 9
>> lacks localization. what are this lists feelings on localization (both
>> translation of strings and formatting of numbers, time etc.) of user-facing
>> applications?
>>
>> the only model i know right now is gettext() and related from GNU; there's
>> gotta be a better way; perhaps an fs for it? ;-)
>
> As an example of the joy of the localization, switching recently KerGIS
> servers from NetBSD 3.x to NetBSD 5.x, the same code recompiled would
> give errors, with cryptic messages, until I happen to pin the problem to
> the formating of numbers... I use, as a backup version of files, a text
> (mainly ASCII) transcription of the data, and use 'd.d' for example. But
> since users had LC_ALL set to french, NetBSD 3.x didn't support nor time
> neither number localization so no problem, but 5.x now does. Result :
> "french" 'd,d' was expected for input; and 'd,d' sent for output. Joy!
>
> For another mean instead of gettext(), you have what has done Donald E.
> Knuth with TeX and al: : all the strings are extracted in a "pool"
> file---a text file---, so as long as one sticks to the index (the
> position), one can provide a translated pool file to localize.
>
> Furthermore, IMHO, there are 3 levels:
>
> - 0: firmware/kernel: LANG C (a restricted faulty subset of english)
> - 1: system libraries and utils, directly used by programmers, not
> really users: LANG C (idem)
> - 2: user level scripts or programs; since they are adapted for higher
> level manipulation, the levels 0 and 1 messages have no meaning for the
> user, so it is useless to translate. And since level 2 shall match the
> user (here is the business!), this is not a problem.
>
> So, for me at least, the best solution to this difficult problem is the
> one provided for Plan9 by Rob Pile and Ken Thompson (I cite the authors
> of the "Hello World or...", i.e. UTF8.
>
> More is too much.

I tend to think that only user programs should be translated, the TeX
approach you describe seems simple enough.
As a brazilian, I have precisely the same feeling of Gabriel Diaz and
I always use the computer in English.

> I particularly enjoy good translations into my language, both in programs,
> books, films, or whatever. I find it, translating, a job to be proud of.
Good translations are very nice, but more difficult the subject of
translation is, the more trouble to find one (at least to portuguese).
And, at least in open source, it seems that translators of portuguese
can't keep themselves motived for the needed time.

Re: [9fans] localization

[smiley]

Lluís Batlle i Rossell <viriketo@gmail.com> writes:

> As for the localisation of software, regarding the implementation to allow
> comfortable localisation without much trade-offs, I can't suggest anything of
> value now.

I think the Plan 9 solution to l10n ("fix it once, fix it right") would
be to have users (and the system itself) speak Lojban.  ;)

  http://www.lojban.org/

(If you read The Moon is a Harsh Mistress, the language used to program
the computer, Loglan, in the ancestor of the Lojban language.)

-- 
+---------------------------------------------------------------+
|E-Mail: smiley@zenzebra.mv.com             PGP key ID: BC549F8B|
|Fingerprint: 9329 DB4A 30F5 6EDA D2BA  3489 DAB7 555A BC54 9F8B|
+---------------------------------------------------------------+

Re: [9fans] localization

[Steve Simon]

I don't believe there is a program to do it.

The files are re-formatted form of the Unix timezone info. You can get
the latest Unix code from: http://www.twinsun.com/tz/tz-link.htm which
points you at ftp://elsie.nci.nih.gov/pub/.

The timezone is fixed, the hassle is the Daylight saving time
switching days which tend to move around based on the local
government's whim [1].

Timezones are described in an textural table which is "compiled" to a binary
file. All you need to do is convert this output to text (the Unix toolkit contains
such a program) and add the apropriate header to make a plan9 timezone file.

-Steve

[1] wasn't there a case a few years back, of the mayor of Rio changing the
metropolitan area's timezone so its workers could have more time on the beach?
Doesn't sound such a good idea in a rainy English winter...

[9fans] localization

[Sergey Reva]

Hello Fans,

At least I configured my vmware network and can send patches, i am
already sended ukrainian and russian kbmap, and want create timezone
file, i read man page and ask:
does we have program to generate ranges for alternative time (i mean
number after ??? nnn ??? nnn), or I need calculate by self?
--
http://rs-rlab.narod.ru                          mailto:rs_rlab@mail.ru