Op vrijdag 29 juli 2005 12:38, schreef James Bunton: > My position on this is pretty much the same as Daniel's. > > At the moment the code is changing too much to consider a merge. All it > would do is slow our work. It's something to think about when I run of > features to code for PyMSNt.
And what about the other part; merging the communities? > As for the language strings, that sounds quite reasonable. Anybody who > wants to make a start on merging the various lang.py files, go ahead. > I'll help however I can. I'm also willing to be convinced to switch to > gettext, but I haven't looked at it. Maybe it is better to wait until gettext support then. <snip> -- Mvg, Sander Devrieze. xmpp:[EMAIL PROTECTED] ( http://jabber.tk/ ) From [EMAIL PROTECTED] Fri Jul 29 11:52:27 2005 From: [EMAIL PROTECTED] (Daniel Henninger) Date: Fri Jul 29 11:52:23 2005 Subject: [py-transports] gettext, was: Idea: combining Python-based Jabber transports into one project In-Reply-To: <[EMAIL PROTECTED]> References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> >> As for the language strings, that sounds quite reasonable. Anybody who >> wants to make a start on merging the various lang.py files, go ahead. >> I'll help however I can. I'm also willing to be convinced to switch to >> gettext, but I haven't looked at it. > > Maybe it is better to wait until gettext support then. Well, that's actually a question I wanted to pose. =) How do people feel about gettext? Here's my thinking with it. gettext is a known. It's used in many applications written in all kinds of languages. I'd almost bet there are little helper tools out there that work with gettext formatted files as well. In other words, it's been around, it's popular, it seems to do the job... Question is, is it buying us anything to switch to it? Language files would be separate per language instead of "all in one". When someone submits a language file it'd literally be a drop-it-in-place scenario, no patch or merge into an existing file. But it does mean that our code would have english text in it instead of shorter "lang.whateverIwant" things. One "negative" about it might be that... well lets say we have an error message that's translated called "ninjaFailure". If we wanted to change the text of that error message, right now we go edit the english ninjaFailure in lang.py. With this, we would need to be sure to find every instance of it that looked like: _("The ninjas have failed to do their job.") => _("The ninjas were not successful.") and if we don't get all of them, we effectively have multiple strings. Like if I had: _("The ninjaas were not successful.") somewhere.. that's an entirely different string than the first one. That said, if we're careful, that won't be a problem. The biggest benefit I can see is that it's a known. Anyone have any feelings on gettext vs homebrew for internationalization? (BTW, I don't know how familiar you are with gettext's suite of tools, but it also has a tool to pull all of the _("...") strings out of your code for you so you don't have to worry about forgetting to pull some of them.) And also, what supposedly happens is you get this text file filled with english text strings that you hand out to your translators, they translate each line and hand it back, and you just copy the file into whatever path you chose to put the translations in as .. say... fr.po or en_us.po or something like that. (I think it's .po it gets "compiled" into a fast lookup format) Anyway, I'll look into the code aspects of it and work on a test pyicq or pyaim using gettext so we have something to look at to see if we like it. Stay tuned.. Daniel
