Ed, I hope you've looked at Pootle. We now have a Summer of Code developer working on putting infrastructure in place that could allow something like what you propose.
But I would do it or use it slightly differently. The problem as I see it is not so much that there is lots to translate but that we don't target what we do. For instance would you know what applications need to be translated on for instance the GNOME desktop? No, neither does anyone from GNOME. And those that need to be done, how much of it actually needs doing? Has anyone ever seen that error message. I would use the system you propose to allow the users, by simply using applications to target translations. The good thing is that users of any language are helping to shape the priority within the scope of an application. And users of the target language set the scope simply by launching an application. I wrote this page on doing profiling using existing Gettext related tools: http://translate.sourceforge.net/wiki/guide/direction/profiling So we would end up with something like this. 100% of users use gnome-panel while 25% use gnome-tetris. Clearly we do gnome-panel first its also quite obvious in this case why it would be first. So know we are translating GNOME panel and we see that only 45% of messages are used over 50% of the time (I'm making that up). So we target those messages. The problem about translating a message one at a time is that we lose context. So my proposal would be that these message are still translated in a web service such as Pootle. Or even a local application that communicates with Pootle. But we would always translate within context ie what message are before and what are after. The translator would then translate until the point at which they should begin translating another application not when the application is 100%. So some idea of a diminishing returns. On Sat, 2006-07-01 at 21:35 +0930, Clytie Siddall wrote: > Ed, I have forwarded this to the Pootle list. :) > > Have a look at the Pootle links [1], especially the roadmap. I think > what you're talking about could certainly plugin to Pootle, although > it would require a change in the way applications use localized > strings. Currently, it's perfectly easy to update a gettext > translation (PO file) online via Pootle, exactly as you say. However, > that translation then has to be plugged back in while recompiling the > target software. Mac OSX (Appleglot) translations can utilize updated > translations (.lproj folders) when rebooted. > > On 29/06/2006, at 2:08 PM, Ed Trager (Unicode Font Guide: http:// > www.unifont.org/fontguide/) wrote: > > > > I have recently been doing a fair amount of AJAX stuff. It's powerful > > stuff. And it gets one thinking about turning *every* application into > > one that seamlessly grabs data from remote servers on the fly as it > > needs it. > > > > So here's an idea on how this problem could be solved in the future, > > with benefits for both users of common *and* uncommon languages: > > > > Suppose that we write a message translation service daemon that > > retrieves translated message strings from remote servers over the > > internet. A software application on the user's machine hands the > > service daemon an English message string, "Save All" , and a target > > locale, "fr_FR" , and the service daemon retrieves the localized > > French version, "Tout enregistrer", for example. Of course, the > > service daemon might need more information than just this. For > > example, it might need to know which server or servers to query, or at > > least the name of the application to query, for the latest > > localization messages for a particular piece of software. But this is > > not difficult to provide. > > > > True, popular software is already well-localized for common languages > > like French and Chinese. There is no need to find out the correct > > French translation of "Save all" because the installed software > > probably already has the localized message for that one. But even > > here, the latest versions of popular software packages are often not > > 100% translated. Some percentage of message strings remain > > untranslated at the time when the latest version is released (or > > packaged by Linux or other FLOSS distributors). So this is where this > > daemon comes in really handy for common language users : Over time, > > their localized software silently becomes more completely localized > > without the user having to upgrade anything. It all just happens in > > the background when the CPU would be otherwise relatively idle. In > > effect, as soon as new translations of message strings are available, > > the user gets them installed automatically. > > > > For less-common languages, the effect would be even more enticing. > > One day, your software is stuck in English because nobody has posted > > any translations in your preferred primary locale at all. Then, all > > of the sudden, a day comes along when a new translation team has > > suddenly posted a slew of messages on the server and -- bang! -- One > > day you open up your application and the localizations are just there, > > like magic! > > > > In fact, this network-based system would be very good for the language > > users themselves. As a user, I could start translating my favorite > > app without every having to learn about GNU gettext and PO files and > > UTF-8 and Unicode and Normalization Form C and ... blah blah blah. > > Just visit the online localization center for my favorite software and > > start typing translations of untranslated strings. Next time I turn > > on the software on my local machine --voila!-- my own message strings > > get downloaded and used. And of course, they get downloaded by > > everyone else too. > > > > Also, if the online translation centers are handled in some sort of > > wiki style , initially "poor" and "fuzzy" translations could be > > automatically replaced with "good" translations over time as more and > > more people contribute to the effort. Client software could easily > > have a "Check for localization updates" feature to run a blanket check > > of all message strings against the server-side database instead of the > > normal, behind-the-scenes checks for just the missing strings. > > > > I'd like to hear what people think of this idea. > > > > -- Ed > > [1] > http://translate.sourceforge.net/wiki/pootle > http://pootle.wordforge.org/ > http://translate.sourceforge.net/wiki/wordforge/functional_specificaions > > from Clytie (vi-VN, Vietnamese free-software translation team / nhóm > Việt hóa phần mềm tự do) > http://groups-beta.google.com/group/vi-VN > > > > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > Translate-pootle mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/translate-pootle -- Dwayne Bailey Translate.org.za +27-12-460-1095 (w) +27-83-443-7114 (cell) Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Translate-pootle mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/translate-pootle
