On Wed, 24 Jul 2002, [utf-7] Beck, Mike wrote:
something like that. Only if Js is enabled it should only point to +ACM- and if there is no js than we don't need to add the onClick. Do we allready have some js-checking? after all we are using some js every now and then. And of course we will have to give the section (+AD0-filename) as well, and the function might have to add the language.
Ok.
+AD4- I have the configuration variable there on purpose, as in +AD4- some cases I run +AD4- with limited screen space, and I would want to turn off the +AD4- help links, as +AD4- I know what I am doing. agreed. though what i am thinking of is a graphic of 10+ACo-10 pixels (because i want to also have it on the side of inputs) and just a text ? is not really obvious enough (that's for the alt in case you also switched off graphics +ADs--)
I would rather have just text than a graphic loading up, as it scales better.
+AD4- I think XML masters would be ideal, as with XSLT stylesheets on our +AD4- master side when we are rolling a package, we can build all the +AD4- documentation easily. There would also be room to produce more formats +AD4- easily from the XML, such as Info, LaTeX and PDF. I don't +AD4- know if one can +AD4- do this from SGML or not.
yes, there even i agree XML would be a good move +ACo-lol+ACo- well i wanted to do some reading on this topics anyway..
There is a little surprise I have to merge later on into phpMyAdmin, I'm going to merge it after the SQL parser. It makes use of XML. (Note: It is _very_ optional, but cool to use)
+AD4- +AD4- 3) i expect nobody ever really hoped we could get the whole docu +AD4- +AD4- translated, or? +AD4- It will be a slow process for documentation, but it can be done in the +AD4- long term. at least then we should think of having the files for different languages. (allthough i expect it would be ok to have the install only in english). but
I would say that the install should be in all langauages.
then there is two problems: the whole doku in all the languages would be quite a package, so i'd suggest that the documentation would be split from the main package and is downloaded seperately in the language the user wants (this also spares us to have 30 or 40 copies of the english text at the beginning while there is no translation for some language and we need a file with that name +ADs--)
That is probably a good idea.
The main PMA can be packaged with just english, and then we have 'packs' of other languages available.
Eg: west-europe (spanish,french,german,...) east-europe (albanian,bulgarian,croatian,...) south-europe (italian, greek, turkish, ...) north-europe (swedish, danish, norwegian, ...) south-america (brazilian, spanish, ...) west-asia (hebrew, arabic, russian, ...) east-asia (chinese, japanese, indonesian, ...) etc.
This would cut down on the number of total packages somewhat, while still keeping the sizes reasonable.
Having a 'complete' package as well would be a very good move.
and we'd have to think of a way to handle the translations .... what i could imagine would be to have all strings in a database and do a script that would enable the translators to translate them online and creating their languagefile out of it?
I would actually go against that idea. Have XML master files instead, as those can be kept in CVS a lot easier than a database. Each translator would just open up the XML file in his editor, and update it directly, then post a patch to the tracker. To keep track of when changes are made to the english documentation and not the translations, I suggest having small tag in them that is noted as out of date when the english is updated and the translation isn't.