A Diumenge, 10 de juliol de 2011 13:47:13, Cédric Krier va escriure: > On 10/07/11 13:39 +0200, Albert Cervera i Areny wrote: > > A Diumenge, 10 de juliol de 2011 13:21:25, Cédric Krier va escriure: > > > On 10/07/11 13:11 +0200, Albert Cervera i Areny wrote: > > > > A Diumenge, 10 de juliol de 2011 12:52:58, Cédric Krier va escriure: > > > > > On 10/07/11 12:39 +0200, Albert Cervera i Areny wrote: > > > > > Right now, the translation mechanism gives you the precise place > > > > > where the string is used but not depending on the position (line) > > > > > where it is. Also the gettext syntax just doesn't give you the > > > > > Model from which the string comes. > > > > > > > > You're right. As I said, if self.raise_user_error() (or equivalent > > > > function) accepted the complete string without pre-declaration it > > > > would do the job for me. > > > > > > It will break the fact that right now we know exactly from where comes > > > the string and it is used for translation. With a gettext-like method, > > > you loose this and I think it is bad because the same string in > > > English could have different translation in other languages because of > > > the usage context. > > > > You would with a gettext-like function you would loose that and it > > wouldn't work, but with a "self.raise_user_error()" function it would > > work just like > > > now. Except for the way strings are extracted: > No because the script that will extract the strings will not know from > which Model it comes.
You're right. I see a couple of solutions for this. I guess you won't like any of those, but let me try it ;-) - Use standard gettext's application (which will store filename and line) and move through the stack call to find out who's calling and pick up filename from there. (Translations would be filename based instead of model-based). - Write our own script (or whatever) to extract strings and model name too. > > > > > More over, it will require to parse the python file for those > > > > > string instead of just using the python runtime. > > > > > > > > Of course, my suggestion of raise_user_error() without > > > > pre-declaration would require that too, but I don't see it much of a > > > > problem if it helps developers. After all most of open source > > > > projects are already doing that and there're tools which make it > > > > really easy to do it. > > > > > > This mean the translation process will need 2 steps, one for the > > > translation of the string we know like fields.string, fields.help etc. > > > and one for other translation spreaded in all the code. > > > > Sure, but I don't see much of a problem here as long as it helps module > > developers. Do you see important drawbacks with this? > > Yes the KISS principle. Two way for the same purpose is bad. -- Albert Cervera i Areny http://www.NaN-tic.com OpenERP Partners Tel: +34 93 553 18 03 http://twitter.com/albertnan http://www.nan-tic.com/blog -- [email protected] mailing list
