Re: the ultimate solution to the i18n problem...

1999-11-15 Thread Marc Lehmann

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...

1999-11-12 Thread Marc Lehmann

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...

1999-11-12 Thread Jon A. Cruz

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...

1999-11-11 Thread Eduardo Perez

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...

1999-11-11 Thread Sven Neumann

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...

1999-11-11 Thread Tuomas Kuosmanen

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...

1999-11-10 Thread Ian McKellar

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...

1999-11-10 Thread Marc Lehmann

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...

1999-11-09 Thread tomr

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."



Re: the ultimate solution to the i18n problem...

1999-11-09 Thread Marc Lehmann

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   |
 |