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