Re: [PHP-DOC] cvs: phpdoc / Makefile.in

On Sat, 17 May 2003, Gabor Hojtsy wrote:

> > To get supported encodings by iconv try iconv -l and iso-8859-8-i is not among 
> > them, iso-8859-8 and WINDOWS-1255 are.
> > Besides that, encoding should be consistent in the translated he files, 
> > currently there is:
> > <?xml version="1.0" encoding="iso-8859-8-i"?>
> > <?xml version="1.0" encoding="iso-8859-8"?>
> > <?xml version="1.0" encoding="iso-8859-1"?>
> 
> Well, iso-8859-8 and iso-8859-8-i are not the same as far as I learned. 
> The question is if the files under the iso-8859-8 XML encoding header 
> are in what encoding? Probably all of the files under iso-8859-1 are 
> really iso-8859-8-i files (as Shimi said they used this encoding for 
> translation, but probably forgot to change the XML encoding header).

Correct. They're not the same. Actually, they're simply reverse. 

To put that "in english terms", if I write:

php.net 

at one of the encodings, and then set the encoding to the other one, I'll get:

ten.php

displayed.

Background (why do we have two encodings?):
In the begining, computers never spoke hebrew (only these days Intel is 
producing their new chips in Israel ;)). In the DOS era, we used ASCII 128 
to 154 with our alphabet, and had special characters burned at the 
graphics adapters to display hebrew. Then came the GUI OSs. The hebrew 
characters were at a set that ISO called iso-8859-8. Like I said, there 
was a simple translation table that gave Hebrew letters.

The problem with iso-8859-8 was that it was impossible. Because computers 
read text and display it from left-to-right, in order for hebrew to be 
displayed correctly, we had to write it backwards (like writing 'olleh' 
instead of 'hello'). That was a pain in the ass. This is why it's called 
"Visual ordering Hebrew", Hebrew that is stored in a way that Visually it 
will be readable. But like I said it was a pain in the ass, and eventually 
microsoft came with a non standard "Logical ordering Hebrew", i.e. hebrew 
that is stored at the same order that it is written at, and the reading 
program simply reverses what it reads. So we can type hebrew normal at the 
same way we write in the normal daily use, and the program does the rest 
in the background.

ISO-8859-8 doesn't exist anymore nowdays, and is only maintained in some 
old sites (Derick mentioned ha'aretz, that's one of them), that had made 
their server side solution do the reversing, so they input iso-8859-8-i 
but the site outputs iso-8859-8. That method is supported by ALL the 
browsers, because no reversing of the letter ordering should occour.

That being said, I hope that it is now obvious that since we type what we 
type normally, ALL the translations are in iso-8859-8-i (aka 
windows-1255), because NO ONE is nuts enough to write everything reversed =)

> 
> > AFAIK the input encoding should be 8859-8 or WINDOWS-1255. Output encoding is 
> > set to 8859-8 by the xsl-sheets. The question: why is iso-8859-8-i used in he 
> > files?
> 
> Because iso-8859-8 is deprecated as far as I know and iso-8859-8-i (also 
> known as windows-1255) is favored instead. So the XML headers as well as 
> the output encoding should be changed to the used encoding: iso-8859-8-i 
> or windows-1255. As the latter is known by xsltproc, let that be.
> 

Right :)

> > The entiity files:
> > language-defs and language-snippets might be changed, as suggested by shimi
> > iconv -f windows-1255 -t utf-8 to make xsltproc happy;-)
> 
> Great.
> 
> > At least my tests have shown, that this works fine, at least xmllint and 
> > xsltproc doesn't complain about encodings. Can't say anything about the 
> > results, because i can't read hebrew:-)
> > 
> > Testing:
> > 1. I applied iconv conversion to the two entity files
> > 2. changed encoding to WINDOWS-1255 in the curl folder of he tree and other 
> > files in question (maybe this should be 8859-8).
> > 
> > Results (processed with xsltproc) can be found online at:
> > www.holliwell.de/he/
> 
> Can someone from the he group check this?

That is readable fine, at encoding iso-8859-8-i at the browser (good).

Still, although the letter ordering is fine, it is aligned left-to-right, 
and that is a problem, because when Hebrew is mixed with english, 
browsers split the line to hebrew-english-hebrew-english, and although 
making the order of the hebrew letters right, the text has to be read like 
this:

1. most left hebrew part
2. the english that comes on the right of it
3. the hebrew that comes to the right of it
4. the english that comes to the right of it

and so on :) 

the solution to this is simple: to change <html> to <html dir="rtl">
also, the encoding isn't set automatically as of now, and 
<meta charset="iso-8859-8-i"> will help. (Yes, we need the ISO name here, 
all the browsers support it, and not all of them support the windows-1255)

-- 

  Best regards,
     Shimi


----

   "Outlook is a massive flaming horrid blatant security violation, which
    also happens to be a mail reader."

   "Sure UNIX is user friendly; it's just picky about who its friends are."