Gregor Horvath wrote: > Ian Bicking schrieb: > >> That would be fine, but for this case we might also just put >> "gettext_domain='FormEncode'" into the class too, no? It seems >> reasonable to set the domain to 'FormEncode' by default. >> > > yes, but the standard gettext function does not accept a domain argument > like the TG gettext function does. Instead the domain is definied at > creation time of the translation object: > > import gettext # standard > t = gettext.translation(domain='FormEncode', \ > languages=None, \ > fallback=True) > _stdtrans = t.ugettext
Ah. OK then, your strategy sounds right then. Though I guess it means that TG will have to do: Validator.gettextargs['domain'] = 'FormEncode' ? I.e., it will have to TGify the Validator class on startup. How does the turgogears.mo file get generated? Is it every translatable string in TG? Or is it every translatable string in the individual project? If it's just the project itself, then an extraction process that understands validators and schemas could do it. If not, then people will have to carefully look at their code to see what portion of FormeEncode.mo needs to be translated (assuming they don't feel like translating the entire thing, though I suppose contributors could translate it and distribute the entire translation with FormEncode itself). If FormEncode does start distributing translations, I should say that I don't really want to manage that process, though I'm more than happy to give someone access to manage that. -- Ian Bicking | [EMAIL PROTECTED] | http://blog.ianbicking.org --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "TurboGears" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears -~----------~----~----~----~------~----~------~--~---
