But we cannot autodetect what English and what is translated. This will mean that
Why don't we? Code (PHP, user notes...) comes in English (you can't translate the function names! PHP knows only english ;))
You got the answer below in my original letter don't you? I have provided reasons there...
a) non translated pages will go out to the browser with
iso-8858-8-i but with English conetnt
I thought that if the page was not translated, a copy of the English is placed instead of it? I mean, simply generated from English, and placed there?
The whole conversation started out with the problem that the manuals are generated as a whole. Please read back.
b) English text on these pages will be RTL
If I am wrong and it reads the english and enforces the hebrew properties (for no good reason...) - then yes - this will be true, I guess. But if it's ture, I can't understand the idea behind compiling a different page that is equal to a different page, instead of, for instance, include()ing the relevant /en/ page... (but that's just me...)
It is not equal. The whole discussion on Hebrew issues started from the problem that the whole manual is built and therefore we have problems with entities translated. Do you remember? Non-translated pages are not equal in a translated environment. The TOCs on those pages are not the same, the generated text parts (Table 3.2, Figure 4.5, etc.) are not the same, the sections with snippets are not the same. So if we introduce RTL then all the untranslated pages will be RTL but in most of the time English (except translated snippets on the page and translated TOC titles which will be Hebrew).
c) Code blocks used for explanation will be LTR even if
translated [eg. http://www.php.net/manual/en/install.macosx.php]
Right, but since they *are* code blocks, they have to be LTR, because otherwise they'll not be readable (for instance, --with-mysql will become with-mysql-- and that's really not good...). If we translate something there, it's just the title, and since it's one non complicated line, it is... bearable. Preferred to be that way rather than having the whole code RTL.
OK.
This raises another point which I've noticed while going over my translated page. Sometimes inside the Hebrew explanation, we have to give an example of a configure option (like --with-mysql=[DIR]). And the phenomenon I talked about in the past paragraph - happens there. See: http://shimi.staff.fresh.co.il/ref.mysql.html (and set your browser to RTL)
See what happens. I guess we need the <span> thingie over there too :( I wondered if all those <option> and <literal> tags in the XML are also translated through some CSS. If the answer is yes, this is not a problem... for the solution I've already made.
Well, this was the point of starting a discussion and not just 'fix' the CSS the first place. Treating this a simple problem, getting out with a solution is not good at all, if it turns out that there are other things to consider and that the whole time spent on implementing a solution worth nothing. So one again I would like to ask you to go through the translations and collect the parts which should be LTR. Please don't just mention a few tags. I would be happy to see a reasonably complete list, so we know how big is the problem, and from where we should fix it. There are no CSS classes for <literal>, <option> and the like for example, they are all <tt>s in HTML.
English comments will be translated inside the examples to Hebrew? Or
comments? as in user comments?
"comments inside the examples" mean PHP comments inside code examples from the manual and not user comments. See the official code example on http://www.php.net/manual/en/function.echo.php. So you are not going to translate those comments inside official code examples?
I will translate them - it is possible to read hebrew in LTR mode if it's not a complex text. Moreover, in textbooks notes in code are always displayed aligned to left, to be "English compatible", "because it's a code"
OK. So this is not a problem.
what to do with those parts, where a programlisting is [mis]used to present content. This kind of usage is common in the installation part, where it wouldn't look nice probably to have code blocks after every sentence, so the whole explanation is put under one code block.
i totally lost you, but generally, like i said, if it's english, it's ok for it (and it is preferred that way) to be in left-to-right...
Ups, I guessed you know the installation parts I was referring to. See the code usage I referenced in point c) above. That is not example code, is text. Would you translate that? Wouldn't it be bad to show that LTR?
Well, I would translate the real text there (which is not part of the example, like: //let's connect to the db, and what is pure CODE, I'll put in CODE tags, even if the original manual page didn't do so... if it's code, it should be treated that way...
So you are going to move the explanation out of the example? That's fine with me. :)
Goba