Ubuntu-RTL Digest, Vol 6, Issue 10

[Yaron Shahrabani]

Yaron Shahrabani

<Hebrew translator>


On Fri, Dec 24, 2010 at 1:42 AM, Chris Scaife <scaife.chris at gmail.com>wrote:

> It is a practical issue. Program source code is not intended to be handling
> text from multiple locales. (In fact I think the C standard says source
> files must be entirely ASCII). However, translation files do need to support
> it. In this case when inserting part numbers in a translation LRO and RLO
> are necessary to make the .po file intelligible and usable to the one
> editing it.
>
I don't see any problem here as well, you can't add Unicode strings in
places where they don't belong, forget C, any programming language has a
syntax, some strict and some less strict but it does matter what other chars
you put outside the quotes (in that matter).

There is only one important issue here:
char c;
c = "☺";

Although C99 is ASCII only we will break the rules just for the
demostration, the string inside the quotes will be handled by the compiler
as data, the name of the variable doesn't really matter, its a cell in our
memory that should hold an ASCII char.

The compiler has no way of dealing with strange types of data, if you define
new functions with Hebrew names for example you can call them afterwards,
lets define a function called גבר_גבר, we can use unicode in that case since
we defined the function that way and the compiler knows what to do with it.

Things that are out of the regular syntax are not interpreted correctly
anyways, if I would type msgidr instead of msgid it would lead to the same
problem, in both cases I just broke the syntax.
You can increase readability by typing directionality characters inside
quotes since quotes have no directionality anyways so trying to influence
them makes no sense...

>
> While there are multiple ways to achieve the very same appearance on the
> screen, most programs not written with this in mind will consider text with
> different embedded overrides in different places  as completely different
> text... thus resulting in malfunction on things like a database lookup or
> even a simple string comparison.
>
I might need to ask you to explain that again, it could be the late hour
though ☺

>
> While it would be relatively easy to modify msgfmt to treat directionality
> codes the same way as it treats spaces, perhaps it isn't a bug and I just
> need someone to explain how to deal with this situation effectively.
>
This could be a great idea, so you are basically saying that the compiler
should ignore directionality chars by means of syntax? that seems doable
although not that practical, I'll sure forward your idea and see if there's
any use for it.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.ubuntu.com/archives/ubuntu-rtl/attachments/20101224/454ab522/attachment.htm