Op woensdag 27 juli 2005 16:11, schreef Daniel Henninger: > > Op woensdag 27 juli 2005 13:57, schreef Daniel Henninger: > > <snip> > > > >> One problem with that is, our lang.py's aren't the same. There are > >> messages that AIM and ICQ have that MSN does not. (and there will be > >> more) So at that point we might end up having a lot of "hey, > >> translator, > >> I'm really sorry, but you only translated the common stuff, can you > >> translate the transport specific stuff too?" > > > > I don't think that is a problem. I think it is a good thing to bring the > > communities a little bit more together. > > I'm ocnfused then. Are all of the trnasports just to NOT have language > strings that aren't common across the board? That's certainly not going > to happen.
Of course not, but some strings can be like this: "Error: $transport_name couldn't connect to your $network_name account." > We certainly can't use the same lang.py file if the strings > aren't going to be exactly the same. The closest compromise I could think > of is to throw all of the common ones in a lang.py file and have > lang-extended.py or something for things that were beyond common strings. What I initially meant is that the lang.py of every transport will be the same file, including *also* the strings that aren't used for this transport. This will make the disitribution a bit bigger, but it will be a lot easier for translators. Other idea: a script that automatically can combine and split lang.py files. So translators can use a file with all strings in it, and you can easily extract the PyAIM-t and PyICQ-t strings from it. > At one point I was thinking about switching to gettext strings anyway. I > was going to research that and see which people preferred. Still might. > I keep wavering as to whether gettext is a "good idea" or not for this. Also nice :-) > *chuckle* I simply like my own. I've been integrating a lot of things > I've "always wanted in other products" and integrated it with my site in > other ways. I really have no intention of changing that. ...or your own. :O) So the idea is that people go to a web page, select there the transport, and file the bug/wish. > Also keep in mind that James and I are both still working on different > things with the pytransports and haven't gotten to a point where syncing > up completely is really reasonable. For example, he's working on file > transfer and avatars while I spent some time to get a web interface and am > going to work on database-driven spools and such. At some point I'm sure > the two of us will evaluate what all we have and work in importing each > others work. The advantage of a merged codebase in Subversion would be, I guess: * importing is not needed anymore. * users that only can test PyMSNt (as they don't have an AIM or ICQ account e.g.), can still test the webinterface and give you feedback (patches, bug reports, suggestions). <snip> -- Mvg, Sander Devrieze. xmpp:[EMAIL PROTECTED] ( http://jabber.tk/ ) From [EMAIL PROTECTED] Wed Jul 27 15:25:37 2005 From: [EMAIL PROTECTED] (Daniel Henninger) Date: Wed Jul 27 15:25:34 2005 Subject: [py-transports] 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]> > Op woensdag 27 juli 2005 16:11, schreef Daniel Henninger: >> > Op woensdag 27 juli 2005 13:57, schreef Daniel Henninger: >> > <snip> >> > >> >> One problem with that is, our lang.py's aren't the same. There are >> >> messages that AIM and ICQ have that MSN does not. (and there will be >> >> more) So at that point we might end up having a lot of "hey, >> >> translator, >> >> I'm really sorry, but you only translated the common stuff, can you >> >> translate the transport specific stuff too?" >> > >> > I don't think that is a problem. I think it is a good thing to bring >> the >> > communities a little bit more together. >> >> I'm ocnfused then. Are all of the trnasports just to NOT have language >> strings that aren't common across the board? That's certainly not going >> to happen. > > Of course not, but some strings can be like this: > "Error: $transport_name couldn't connect to your $network_name account." Well I've got no objection to stuff like that. >> We certainly can't use the same lang.py file if the strings >> aren't going to be exactly the same. The closest compromise I could >> think >> of is to throw all of the common ones in a lang.py file and have >> lang-extended.py or something for things that were beyond common >> strings. > > What I initially meant is that the lang.py of every transport will be the > same > file, including *also* the strings that aren't used for this transport. > This > will make the disitribution a bit bigger, but it will be a lot easier for > translators. So you mean that a single lang file from say, PyAIM, would also contain the "special strings" from MSN and ICQ but would just ignore them? I don't think I'd have anything against that. > Other idea: a script that automatically can combine and split lang.py > files. > So translators can use a file with all strings in it, and you can easily > extract the PyAIM-t and PyICQ-t strings from it. I don't know, I really don't see any reason to not compile all of the strings into one big one (except that, at present, I'm sure James and I are operating in "oh, crap, I need this string too" mode so it's a little unstable to combine right now). Ideally we'll get to a point where we've figured out what all strings we need and can say "hey, please translate all of these". But I dont' know, James? What do you think, should we put together a big lang.py file that we both are willing to download for our releases that contains everything? Store all of the translations and such in a single place? (I'd be happy to offer said tool and maintain it) > >> At one point I was thinking about switching to gettext strings anyway. >> I >> was going to research that and see which people preferred. Still might. >> I keep wavering as to whether gettext is a "good idea" or not for this. > > Also nice :-) *chuckle* Well we'll see. I'm wary as to whether it looks cleaner in code to see: lang.get(lang.greetingMessage) or whatever or _("Hi, Welcome to XXX, I'm a ninja!") Furthermore, the former allows us more leeway to do things like variable substitution. > >> *chuckle* I simply like my own. I've been integrating a lot of things >> I've "always wanted in other products" and integrated it with my site in >> other ways. I really have no intention of changing that. > > ...or your own. :O) So the idea is that people go to a web page, select > there > the transport, and file the bug/wish. > >> Also keep in mind that James and I are both still working on different >> things with the pytransports and haven't gotten to a point where syncing >> up completely is really reasonable. For example, he's working on file >> transfer and avatars while I spent some time to get a web interface and >> am >> going to work on database-driven spools and such. At some point I'm >> sure >> the two of us will evaluate what all we have and work in importing each >> others work. > > The advantage of a merged codebase in Subversion would be, I guess: > * importing is not needed anymore. > * users that only can test PyMSNt (as they don't have an AIM or ICQ > account > e.g.), can still test the webinterface and give you feedback (patches, bug > reports, suggestions). Well at present I -reallly- don't deal well with people having direct access to the code I'm working on. And at present I really don't have time to learn how to deal with it unless we want even slower progress with pyicq and pyaim. ;D And regardless, I still am not really a fan of the concept of merging the codebases. Hell I don't even want to merge the codebases of my own two. ;) The webinterface and such can be tested whenever James might have time to import it into his own stuff. For now, I'm in no -hurry- to get bug reports/suggestions. ;) They'll come in as they are found and as people have time to test/are interested in testing them for whichever transport in question. Daniel > > <snip> > > -- > Mvg, Sander Devrieze. > > xmpp:[EMAIL PROTECTED] ( http://jabber.tk/ ) > _______________________________________________ > py-transports mailing list > [email protected] > http://www.modevia.com/cgi-bin/mailman/listinfo/py-transports > > >
