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
