Menu
▾
▴
Re: [OctDev] Re: octave-forge translation packages
|
From: Paul K. <pki...@us...> - 2005-07-14 03:25:35
|
It's hard to understand all this because we're making it up as we go=20 along. Assuming we have people motivated to do the translations and tools to=20 help them figure out what needs to be translated and what has changed=20 since it was last translated, how should we organize the translated=20 packages in a way that is convenient for package maintainers,=20 translators and users? Package maintainers want to release their package when they are done. =20= They don't want to wait upon a half dozen translators who may or may=20 not care about their particular package to finally get around to=20 finishing the translation. Translators want a big set of text to translate. They don't want to go=20= through 20 different packages checking which strings are still needed or which translations are now out of date. Users want the translations for their language to be distributed with=20 the packages they want to install. Any suggestions how we can organize the translation effort to achieve=20 this contradictory goals? - Paul On Jul 9, 2005, at 9:23 AM, S=F8ren Hauberg wrote: > Sorry about the late reply... > I must admit I don't understand all of this, which makes it hard for=20= > me to answer wether or not my package system could be used for this.=20= > Is 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=20= > be rather trivial. I just don't see how you would translate=20 > non-standard error messages or any other kind of function specific=20 > text output. > > Most of the programs I run on my PC are translated into Danish, which=20= > is 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=20= > in two languages. I'm saying this because I have a very strong feeling=20= > that Octave would end up being such a program. Atleast, I know I get=20= > alot of code from different people around the world, and these people=20= > would most 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=20= > stuff? > 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, >> I suggest we put translations for various octave packages in a new=20 >> top-level directory in the octave-forge CVS server: >> octave-lang >> I recommend keeping the translation for each language as a separate=20= >> distribution to reduce coordination efforts. I don't want to wait=20 >> until the translators for twenty different languages complete their=20= >> work before releasing a package. The translators don't want to dig=20= >> through twenty different packages to see what needs to be translated. >> 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=20 >> installed? Can this be a post-install operation for the package=20 >> manager? Individual packages should of course be able to be bundled=20= >> with their own i18n. >> We will need octave-lang/tools for things such as docstring=20 >> extractors, hash string checkers and other programs to list what=20 >> needs to be translated for each language. I think the installation=20= >> tools should be part of the octave packaging system. >> We will need octave-lang/admin for scripts to build and maintain the=20= >> online docs and distributions. >> We will need octave-lang/zz for each language zz we wish to=20 >> translate, including zz=3Den for those packages whose original = language=20 >> is not English. >> 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>. >> The internal structure of the package directories will be dictated by=20= >> the package system. It will include translations of the usual=20 >> packaging documents such as package description and README. I=20 >> suspect it will have a subdirectory for functions and maybe another=20= >> for the manual and another to contain translated demos. We will=20 >> eventually need a directory for translated warnings, error messages,=20= >> axis labels, etc. We may also want replacement m-files for those=20 >> functions which are to hard to translate string by string. Somebody=20= >> else will have to fill in the details. >> As a convenience to translators, we will need the source documents in=20= >> octave-lang/source/<package-name> with exactly the same structure as=20= >> we want in zz tree. >> Is this as simple as can be and no simpler? >> - Paul > > > > ------------------------------------------------------- > This SF.Net email is sponsored by the 'Do More With Dual!' webinar=20 > happening > July 14 at 8am PDT/11am EDT. We invite you to explore the latest in=20 > dual > core and dual graphics technology at this free one hour event hosted=20= > by HP, > AMD, and NVIDIA. To register visit http://www.hp.com/go/dualwebinar > _______________________________________________ > Octave-dev mailing list > Oct...@li... > https://lists.sourceforge.net/lists/listinfo/octave-dev > |
