[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [bug-gettext] ISO-8859-8 and bidi (was Re: [Translation-i18n] gnulib

From: Vladimir 'φ-coder/phcoder' Serbinenko
Subject: Re: [bug-gettext] ISO-8859-8 and bidi (was Re: [Translation-i18n] gnulib, bison-runtime and texinfo charset)
Date: Tue, 27 Mar 2012 21:14:43 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.3) Gecko/20120324 Icedove/10.0.3

On 27.03.2012 20:49, Eli Zaretskii wrote:
>> Date: Tue, 27 Mar 2012 20:36:22 +0200
>> From: Vladimir 'φ-coder/phcoder' Serbinenko
>>  <address@hidden>
>> CC: address@hidden, address@hidden, 
>>  address@hidden
>> On 27.03.2012 20:11, Eli Zaretskii wrote:
>>>> The biggest problems are the lack of sane migration path and that it
>>>> affects long-term storage.
>>> The migration path is clear: craft a UTF-8 encoded logical-order
>>> he.po.
>> It's not that easy. I expect the original code and accompanying
>> translations to continue to evolve and having one side in logical and
>> another side in visual order makes updates tricky.
> I don't see the problem, sorry.  There are projects that have, e.g.,
> pt.po and pt_BR.po, I assume maintained by different people.  Why
> can't we have he.po and he_UTF-8.po (say)?
pt and pt_BR are for most purposes different languages. The standard for
naming is address@hidden so it would be
address@hidden It would have an effect on all domains and not just texinfo,
in addition the user would have to modify his LANGUAGE to be either
address@hidden or he depending on the applications. It'd be pretty a mess.
The usual intent is that different locale names address issues between
human languages, not technical differences.
While maintaining 2 variants is feasible, I personally see it as
increased effort. Since in example of GRUB, it still has neither Hebrew
nor Arabic translations despite the bidi and gettext announcements from
quite some time ago, I don't see the second variant as likely to be
maintained at all. If I had to choose between address@hidden for texinfo
domain or address@hidden for the "grub" domain, I'll definitely choose the
I'd be delighted if "grub" domain was translated to Hebrew and it would
allow me to better test bidi implementation (I've tested it mainly on
few small examples).
I personally see usage of visual ordering in any long-term storage (as
opposed to in-memory temporal data) as wrong in itself and not only as
creating problems.
>> This would amount to
>> a needless fork and increase in continuous supplied effort.
> Each volunteer needs only to consider her own side of the fork, no
> problem here.
Except if there is no volunteer for one of the sides.
>> Or do you propose to change he.po for texinfo to UTF-8
> If there's overwhelming agreement that most text displays nowadays
> support bidi reordering, I don't mind dropping the visual-order
> translation on the floor and keeping only the logical-order one.  But
> I _do_ want to hear some data regarding availability of
> bidi-reordering consoles first.
This created a vicious circle of bidi support "breaking" existing
translations. I believe that bidi support in gettext would facilitate
the overall migration to bidi-capable terminals just how it facilitated
migration to UTF-8 locales.
>> P.S: any reason for the total lack of Hebrew TP mailing list?
> I don't need a mailing list to talk to myself ;-)
But according to TP there are other translators as well.
Could you perhaps pass on a message as to whether anyone is interested
in translating "grub" domain. Developper (my) help available if needed.
There is currently a bug in the entry editor with bidi but it shouldn't
influence the translation, I have a fix but it's too big and invasive
compared to the problem (cursor positioning when inside RTL text) to
commit during the freeze.
> P.S. Any reason my messages don't appear in the archives?  The thread
> pointed out by Bruno shows replies to my messages, but not my messages
> themselves.  What did I miss?
This ML list is member-only.

Vladimir 'φ-coder/phcoder' Serbinenko

Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]