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.
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.
---
James
On 28/07/2005, at 1:25 AM, Daniel Henninger wrote:
>> 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
>>
>>
>>
>
>
> _______________________________________________
> py-transports mailing list
> [email protected]
> http://www.modevia.com/cgi-bin/mailman/listinfo/py-transports
>
