Hi Pierre, Agreed, and yes the money was there for the resources, but doesn't mean we were smart about it (I.e. of couple of local Japanese restaurant employees had much to do with a couple of of product releasees;) - true story)
I think the issue here is not lack of knowledge on how-best-to-go- about-it (there are many smart people here to pick from for process ideas), but lack of knowledge about the translations (the strings). My reasoning is that, if a language is supported by web2py, its probably because one if its members requires that language and he/she (or someone else) has already contributed to that languages string table. That said, why not put a bit of the onus on the users? if we treat each language as a plugin, and each plugin can be versioned, then each web2py release can have access to the latest and greatest of each of the language dictionaries/plugins (does not mean they all have to be at the version). we publish language dictionaries based on requirement, and not as a default (because keeping up may be need to be some one's full time job) here's an example. lets say we have N languages (including EN). EN (being the prime language of release) would set the bar. Lets say, the EN plugin is stamped with version 1.96.1 . if a user requires a German dictionary for his app, then he may agree to update the German dictionary and bring it to the level on the EN dictionary. Otherwise, the _de_de dict would remain at its previous version (maybe 1.95.2). This is open source, so obviously and as you say, the funds are not there, but there are many users, native speakers for each of the supported languages. If there are many users of any given language, then that's great! Just means that there are many users to help keep things in check. Otherwise, the assumption can be that if any language is failing to keep up the EN, its probably that it is not being used, therefore no harm is done by having a language at a lower version. If at any point, someone requires the language, then he/she should do their best to update those un-translated strings where, once vetted, that language dict could be stamped at the same version as EN. I think by introducing and supporting l18n in this type software development environment, users who use the product can be expected to contribute, lest it become unmanageable. besides, i know for a fact, that even large corporation with way too many funds at their disposal release localized product with the worst possible practices (and questionable string equivalents). At least here, there may be no funds, but there is discussion and many who may be willing and able to help (i think). Maybe we can have a "members only" app on web2py.com, where folks can approved members can go when time permits and update strings. @ release time, Massimo could simply dump those string table to... well to what ever format is required. Versioning for the lang plugins can be set by comparing against the model (EN) --> 1.96.1.<number of translated strings> just a thought, Mart :) On May 20, 2:46 am, Pierre Thibault <[email protected]> wrote: > 2011/5/20 mart <[email protected]> > > > > > > > > > > > not sure if this applies, but just in case... > > > years ago (i think 12, so this may be outdated), i worked in a > > localization team, (although it was a purely windows shop where words > > like dll was all that anyone talked about). Anyways, we adopted a > > method for 1) re-using translations (from translation tool kits (aka. > > TTKs) 2) standardizing on commonly accepted strings (i.e. there aren't > > too many ways to translate a yes/no button ;)) & 3) the language > > specific string tables would grow over time and served the task very > > well considering... (we only had 4 or 5 languages ;) english, swedish, > > japanese, simplified chinese, and french (fr_ca was deemed unworthy at > > the time ;)) > > > anyways, the moral is, that all strings going to UI were ripped out of > > the code and replaced with IDs where the users language selection > > would force load the language specific "satellite dll" @ run time - > > was just a dll with the resource strings in it. > > > perhaps adopting something similar (but no dll's ;) ) would be > > beneficial? > > > Mart :) > > Hi Mart, > > Thank you for sharing this experience. I guess you had the professional > resources to do all the translations. If we use a common dictionary for > web2py, we need all the translations for the languages we support for all > the words before doing a new release. Do we have to resources to do that? I > have some doubts. > -- > > A+ > > ------------- > Pierre > My blog and profile > (http://pierrethibault.posterous.com)<http://pierrethibault.posterous.com> > YouTube page > (http://www.youtube.com/user/tubetib)<http://www.youtube.com/user/tubetib> > Twitter (http://twitter.com/pierreth2) <http://twitter.com/pierreth2>
