[OctDev] Re: octave-forge translation packages

[<so...@ha...>]

Sorry about the late reply...
I must admit I don't understand all of this, which makes it hard for me=20
to answer wether or not my package system could be used for this. Is=20
there a thread I should read, to get the details of how translation=20
should be done?

It seems to me that translating the manual and the help texts should be=20
rather trivial. I just don't see how you would translate non-standard=20
error messages or any other kind of function specific text output.

Most of the programs I run on my PC are translated into Danish, which is=20
very nice, except when a program is only half translated. A partly=20
translated program is very annoying to use as it forces you to think in=20
two languages. I'm saying this because I have a very strong feeling that=20
Octave would end up being such a program. Atleast, I know I get alot of=20
code from different people around the world, and these people would most=20
certainly not translate their functions to Danish.

Anyway, to summarize this post
1) Is there a thread I should read to understand all this translation stu=
ff?
2) Should Octave really be translated? Wouldn't it be better to simply=20
try to translate the manual, and then leave it at that?

/S=F8ren

Paul Kienzle wrote:
> All,
>=20
> I suggest we put translations for various octave packages in a new=20
> top-level directory in the octave-forge CVS server:
>=20
>     octave-lang
>=20
> I recommend keeping the translation for each language as a separate=20
> distribution to reduce coordination efforts.  I don't want to wait unti=
l=20
> the translators for twenty different languages complete their work=20
> before releasing a package.  The translators don't want to dig through=20
> twenty different packages to see what needs to be translated.
>=20
> What do the octave packagers for various platforms think about this? =20
> With complete translations, each language could add 1/2 Mb or more to=20
> the distribution.  Would the octave packaging system be able to fetch=20
> and install the language specific docs for the package being installed?=
=20
>  Can this be a post-install operation for the package manager? =20
> Individual packages should of course be able to be bundled with their=20
> own i18n.
>=20
> We will need octave-lang/tools for things such as docstring extractors,=
=20
> hash string checkers and other programs to list what needs to be=20
> translated for each language.  I think the installation tools should be=
=20
> part of the octave packaging system.
>=20
> We will need octave-lang/admin for scripts to build and maintain the=20
> online docs and distributions.
>=20
> We will need octave-lang/zz for each language zz we wish to translate,=20
> including zz=3Den for those packages whose original language is not Eng=
lish.
>=20
> Translations for the base system will go in octave-lang/zz/octave.=20
> Translations for individual packages (such as the packages in=20
> octave-forge and others) will go in octave-lang/zz/<package-name>.
>=20
> The internal structure of the package directories will be dictated by=20
> the package system.  It will include translations of the usual packagin=
g=20
> documents such as package description and README.  I suspect it will=20
> have a subdirectory for functions and maybe another for the manual and=20
> another to contain translated demos.  We will eventually need a=20
> directory for translated warnings, error messages, axis labels, etc.  W=
e=20
> may also want replacement m-files for those functions which are to hard=
=20
> to translate string by string.  Somebody else will have to fill in the=20
> details.
>=20
> As a convenience to translators, we will need the source documents in=20
> octave-lang/source/<package-name> with exactly the same structure as we=
=20
> want in zz tree.
>=20
> Is this as simple as can be and no simpler?
>=20
> - Paul
>=20