Re: the ultimate solution to the i18n problem...
On Mon, Nov 15, 1999 at 12:11:19PM +0100, David Monniaux <[EMAIL PROTECTED]> wrote: > I have an easy solution. Let us change gettext a little so that it takes > another argument, context. This argument would be ignored when no i18n > takes place, but would be taken into account for the indexing in the .po > files. For instance, we could have: This sounds (technically) ugly. However, if you can embed that info in the string (i.e. technically only one arguments), then it sounds nice. > free | beer-> gratuit i.e. "free\0beer" (although C will have problems with \0 so we might need some other delimiter). OTOH, if the extra argument is a string I could only do this in perl and leave the ugly C detals to Daniel ;) Another way to view this would be to embed some meta-comment into the string, which is in addition used to key the translation. -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Re: the ultimate solution to the i18n problem...
On Fri, 12 Nov 1999, Marc Lehmann wrote: > make it (eg) "its1", "its2" etc... and use an english catalog. We probably > need an en_UK catalog anyway, to correct all these wrong spellings for > colour ;-> I have an easy solution. Let us change gettext a little so that it takes another argument, context. This argument would be ignored when no i18n takes place, but would be taken into account for the indexing in the .po files. For instance, we could have: free | beer-> gratuit free | freedom -> libre This of course needs patches to the gettext suite of utilities, but this is I think the best solution for the thing. Regards, --- David Monniaux Tel: +33 1 44 32 20 66Fax: +33 1 44 32 20 80 Laboratoire d'informatique de l'École Normale Supérieure, 45 rue d'Ulm - 75230 PARIS cedex 5 - FRANCE
Re: the ultimate solution to the i18n problem...
Sven Neumann wrote: > > > > Almost, but not quite. > > > > gettext was a good compromise at the time, but leaves a lot to be desired. > > Especially when one source english term ( "its" for example ) might be > > translated differently depending on context. > > When working carefully with gettext, you can translate all appearances of the > same word differently. Since the location of the string in the source code is > contained in the po files, it is easy (even without knowing the entire source) > to detect in what context/dialog the word is used. Yes, that's true. But it still is problematic. Mainly it makes it more transparent for the programmer in the first place, but it creates a more complex and fragile binding. Personally I think that it's no longer necessary to trick programmers into supporting internationalization like it was back in the early '90s. Especially with the current scope of the Internet and it's community. If some simple web site kept this information in some XML format (perhaps one of those being hammered out by the translation software companies) then it could always be easily converted down at distribution time into stuff proper for gettext. Then later if we found a good replacement for gettext (ICU?), we could have all the needed information in place. -- "My new computer's got the clocks, it rocks But it was obsolete before I opened the box" - W.A.Y.
Re: the ultimate solution to the i18n problem...
> > Almost, but not quite. > > gettext was a good compromise at the time, but leaves a lot to be desired. > Especially when one source english term ( "its" for example ) might be > translated differently depending on context. When working carefully with gettext, you can translate all appearances of the same word differently. Since the location of the string in the source code is contained in the po files, it is easy (even without knowing the entire source) to detect in what context/dialog the word is used. Salut, Sven
Re: the ultimate solution to the i18n problem...
On Thu, Nov 11, 1999 at 10:00:57PM -0800, "Jon A. Cruz" <[EMAIL PROTECTED]> wrote: > gettext was a good compromise at the time, but leaves a lot to be desired. > Especially when one source english term ( "its" for example ) might be make it (eg) "its1", "its2" etc... and use an english catalog. We probably need an en_UK catalog anyway, to correct all these wrong spellings for colour ;-> -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Re: the ultimate solution to the i18n problem...
Sven Neumann wrote: > Eduardo Perez <[EMAIL PROTECTED]> wrote: > > > What about a central site, where developers send their files to be > > translated, and a group of volunteers translates them to as many > > languajes as they can? Perhaps there could even exists a database of > > common expresions ('Yes', 'Save as', 'Are you sure?', ..), so all the > > tedious work would be done automatically. > > This is exactly what gettext combined with an open source tree accessible via > CVS provides. We already have that! Almost, but not quite. gettext was a good compromise at the time, but leaves a lot to be desired. Especially when one source english term ( "its" for example ) might be translated differently depending on context. The l10n .xls glossaries MS has for it's products are interesting, as they include breaking down translations by type, such as button, menu, text, etc. Another example is "Free". Could be on a button to free memory. Could be refering to the cost of the software. Could be refering to the freedom of the software... -- "My new computer's got the clocks, it rocks But it was obsolete before I opened the box" - W.A.Y.
Re: the ultimate solution to the i18n problem...
On Thu, Nov 11, 1999 at 10:23:15PM +0100, Eduardo Perez wrote: > Marc Lehmann wrote: > > > > demand a net-connection and call babelfish for untranslated items ;) > > > > (runs...) > > What about a central site, where developers send their files to be > translated, and a group of volunteers translates them to as many > languajes as they can? Perhaps there could even exists a database of > common expresions ('Yes', 'Save as', 'Are you sure?', ..), so all the > tedious work would be done automatically. > > It does not sounds as the most exciting job in the world (for the guys > doing the translations), but... > > Just an idea. A wild idea: Have a web-based system with browsable catalog of all i18n'ed strings organized by category (Menus, Preferences etc..) that contain the translations.. Then if something bugs you, you could "vote" for a better translation and if enough votes happen, it would be added? :) Tig -- .---( t i g e r t @ g i m p . o r g )---. | some stuff at http://tigert.gimp.org/ | `---'
Re: the ultimate solution to the i18n problem...
Eduardo Perez <[EMAIL PROTECTED]> wrote: > What about a central site, where developers send their files to be > translated, and a group of volunteers translates them to as many > languajes as they can? Perhaps there could even exists a database of > common expresions ('Yes', 'Save as', 'Are you sure?', ..), so all the > tedious work would be done automatically. This is exactly what gettext combined with an open source tree accessible via CVS provides. We already have that! Salut, Sven
Re: the ultimate solution to the i18n problem...
Marc Lehmann wrote: > > demand a net-connection and call babelfish for untranslated items ;) > > (runs...) What about a central site, where developers send their files to be translated, and a group of volunteers translates them to as many languajes as they can? Perhaps there could even exists a database of common expresions ('Yes', 'Save as', 'Are you sure?', ..), so all the tedious work would be done automatically. It does not sounds as the most exciting job in the world (for the guys doing the translations), but... Just an idea.
Re: the ultimate solution to the i18n problem...
On Wed, Nov 10, 1999 at 06:18:54PM +0800, Ian McKellar <[EMAIL PROTECTED]> wrote: > > If it isn't a central server but a local .rc file (that could be sent in by > > translators) then I would think this sounds very cool. > > Local .rc file which can be uploaded to the central server through a dialog > box somewhere. while (on irc) I came to the conclusion the original idea had more hack value, doing it "on demand" also solves the online/offline problem. > People could be required to GPG sign their uploads, and users could choose > to allow translations signed by certain users. certain users != all users ;-> but I think local modifications (read that as customization) would be nice in itself. remeber the menu shortcuts? why not set a new ui standard AGAIN? -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Re: the ultimate solution to the i18n problem...
On Wed, Nov 10, 1999 at 03:50:56AM +0100, Marc Lehmann wrote: > On Tue, Nov 09, 1999 at 09:31:05PM -0500, [EMAIL PROTECTED] wrote: > > > What if _every_ text widget - static labels in particular - was > > clickable and allowed the user to modify the translation and submit it > > to a central server? > > If it isn't a central server but a local .rc file (that could be sent in by > translators) then I would think this sounds very cool. Local .rc file which can be uploaded to the central server through a dialog box somewhere. > > But it is alos very difficult to implement (I think). It would also belong > into gtk+. Yes, it would definately deserve to be part of GTK... > > > translated, simply alt-rightclick on it in the menu and select > > "French" and enter the translation. The next time anyone in the world > > starts the GIMP it contacts the server and gets the translation. > > That's too radical. It would be abused (yes, it would!). Not nececarilly. People could be required to GPG sign their uploads, and users could choose to allow translations signed by certain users. Ian -- Ian McKellar | Email: yakk(a)yakk.net | Web: http://www.yakk.net/ Fax/VoiceMail: +61 (8) 9265 0821 | Home: +61 (8) 9389 9162
Re: the ultimate solution to the i18n problem...
On Tue, Nov 09, 1999 at 09:31:05PM -0500, [EMAIL PROTECTED] wrote: > > demand a net-connection and call babelfish for untranslated items ;) that was not meant to provoke sensible replies, but... > What if _every_ text widget - static labels in particular - was > clickable and allowed the user to modify the translation and submit it > to a central server? If it isn't a central server but a local .rc file (that could be sent in by translators) then I would think this sounds very cool. But it is alos very difficult to implement (I think). It would also belong into gtk+. > translated, simply alt-rightclick on it in the menu and select > "French" and enter the translation. The next time anyone in the world > starts the GIMP it contacts the server and gets the translation. That's too radical. It would be abused (yes, it would!). -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Re: the ultimate solution to the i18n problem...
Marc; On Wed, Nov 10, 1999 at 03:20:07AM +0100, Marc Lehmann wrote: > demand a net-connection and call babelfish for untranslated items ;) That's not realistic, but I think I mentioned a similar idea a long time ago. Or maybe I just kept it in my head because it's a bit silly. What if _every_ text widget - static labels in particular - was clickable and allowed the user to modify the translation and submit it to a central server? If you are using the GIMP in French, and the "File" menu item isn't translated, simply alt-rightclick on it in the menu and select "French" and enter the translation. The next time anyone in the world starts the GIMP it contacts the server and gets the translation. Tom -- --Tom Rathborne[EMAIL PROTECTED] -- http://www.aceldama.com/~tomr/ --"I seem to be having tremendous difficulty with my life-style."
the ultimate solution to the i18n problem...
demand a net-connection and call babelfish for untranslated items ;) (runs...)