[Phpmyadmin-devel] RE: [Phpmyadmin-devel] suggestion for Documentation after 2.3

[Robin Johnson]

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.

-- 
Robin Hugh Johnson
E-Mail     : robbat2 at orbis-terrarum.net
Home Page  : http://www.orbis-terrarum.net/?l=people.robbat2
ICQ#       : 30269588 or 41961639