[Adium-devl] Watching a first time Adium user for 5 minutes

[Evan Schoenberg]

On Jan 28, 2007, at 12:14 PM, Andreas Monitzer wrote:

>
>> Mm?  String comparisons are done in a bunch of places... but how is
>> strcmp(message, "INVALID_PASSWORD") == 0
>> any different than
>> strcmp(message, "Invalid Password") == 0
>
> Well, if somebody changed the English translation to "Wrong
> Password", the second comparison would fail, while the first one
> would still work.

At present, we don't use translations at all.

The "English translation" is the same as no translation at all -- all  
userworld strings are the English form, marked for translation and so  
translated into other localizations if appropriate.

>> The problem was that a new string had been added and we didn't
>> notice.  Specifically, the AIM service now distinguishes between
>> "Invalid screenname" and "Invalid password" whereas previously
>> there was a single message, "Invalid nickname or password".
>
> Well, this is another issue that already delayed 1.0 for a few
> months. Development version of libgaim were merged into Adium without
> checking the changes that were done to it, which caused a lot of
> regressions, which had to be traced back to libgaim.
Moving from libgaim 1.x to libgaim 2.x necessitated a lot of  
changes... but it was not a matter of not checking changes which were  
done but rather a matter of needing to make appropriate changes.  We  
were a large part of the development of libgaim 2.x -- gaim's biggest  
beta tester, in fact.  It could be argued that in the future we  
should only upgrade to released versions rather tan being part of the  
dynamic changes of a developing library... that's a discussion for  
another day, as there are definitely pros and cons.

>> If any part of the string changed, the localization would need to
>> be updated.  "Foo %x" != "Foo %x  bar"... so if we had "Foo %x" =
>> "THIS_IS_FOO_IDENTIFIER–%x" as the translation, that translation
>> would no longer be used if the underlying string changed to "Foo %x
>> bar". We'd need to update the translation.
>
> Well, I assumed that the libgaim-devs don't change the localization
> keys willy-nilly. However, I don't have any experience with the
> working style of the libgaim devs.
Generally, strings don't change.  My point is just that having an  
"Adium localization" via gettext doesn't change anything besides the  
parsing out of substituted strings... it isn't somehow a magical cure  
for keeping up to date with library changes.

>> Part of the problem with such a split is that since the Gaim core
>> supports plugins which could do anything, including providing
>> additional protocols, you can't have a centralized singlee list of
>> possible messages.  There's just so much text passed from protocol
>> to core to UI... it'll be a huge undertaking to find a way to do
>> that in a non-UI (identifiers rather than text) fashion.
>
> Ok, that's a problem. The issue is that libgaim might not contain all
> localizations Adium offers. I know a few people here that would be in
> a great panic if their german Adium would suddenly pop up an english
> message (since they wouldn't understand it).
Well, right now there are quite a few messages which come up in  
English regardless of what localization Adium is running in,  
precisely because they come from libgaim, we don't use libgaim's  
translations, and we don't have explicit handling of the message in  
Adium.

Gaim is translated into 61 languages... I'm fairly sure they aren't  
all 100% translations, but I don't envision there being a situation  
in which Adium is translated into a language Gaim is not.

-Evan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://adium.im/pipermail/devel_adium.im/attachments/20070128/2bb7229b/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
URL: <http://adium.im/pipermail/devel_adium.im/attachments/20070128/2bb7229b/attachment.sig>