Menu
▾
▴
octave-dev
|
From: Paul K. <pki...@us...> - 2005-07-06 01:38:01
|
All, I suggest we put translations for various octave packages in a new top-level directory in the octave-forge CVS server: octave-lang I recommend keeping the translation for each language as a separate distribution to reduce coordination efforts. I don't want to wait until the translators for twenty different languages complete their work before releasing a package. The translators don't want to dig through twenty different packages to see what needs to be translated. What do the octave packagers for various platforms think about this? With complete translations, each language could add 1/2 Mb or more to the distribution. Would the octave packaging system be able to fetch and install the language specific docs for the package being installed? Can this be a post-install operation for the package manager? Individual packages should of course be able to be bundled with their own i18n. We will need octave-lang/tools for things such as docstring extractors, hash string checkers and other programs to list what needs to be translated for each language. I think the installation tools should be part of the octave packaging system. We will need octave-lang/admin for scripts to build and maintain the online docs and distributions. We will need octave-lang/zz for each language zz we wish to translate, including zz=en for those packages whose original language is not English. Translations for the base system will go in octave-lang/zz/octave. Translations for individual packages (such as the packages in octave-forge and others) will go in octave-lang/zz/<package-name>. The internal structure of the package directories will be dictated by the package system. It will include translations of the usual packaging documents such as package description and README. I suspect it will have a subdirectory for functions and maybe another for the manual and another to contain translated demos. We will eventually need a directory for translated warnings, error messages, axis labels, etc. We may also want replacement m-files for those functions which are to hard to translate string by string. Somebody else will have to fill in the details. As a convenience to translators, we will need the source documents in octave-lang/source/<package-name> with exactly the same structure as we want in zz tree. Is this as simple as can be and no simpler? - Paul |
|
From: <so...@ha...> - 2005-07-09 13:24:07
|
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 |
|
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 > |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X