todo

[Evan Schoenberg]

On Apr 7, 2007, at 11:39 AM, Mark Doliner wrote:

>> - Fix the upgrade path, currently we lose all gtk prefs (due to prefs
>> name change from /gaim/gtk to /purple/gtk), and lose the set of  
>> enabled
>> accounts (due to ui='gtk-gaim' change to ui='pidgin')
>
> Can we just change all these back to /gaim/gtk and gtk-gaim?  That  
> should make
> things work again with the least amount of work.  My guess is that  
> they were
> unintentionally changed during the sed'ing.  I vote for dealing with
> purple_prefs_rename()ing everything later.

*nod* Nobody in userspace will see the preference names; a quick  
rename back would get us on track for 2.0.0.  If it's going to happen  
at all though we should probably make the rename path (which perhaps  
could be automated at the read-and-rename level? if a pref doesn't  
exist, then look for it with 'gaim/gtk' and such?) a blocker for 2.0.1.

>> - Separate translations for libpurple/pidgin/finch
>
> This sounds like more work for the translators with little gain.   
> But I guess
> it would allow Adium to re-use our libpurple translations?  Sounds  
> good to me.
I'd *love* to be able to reuse translations -- so much translation  
work! -- but I don't think that's a viable immediate goal in terms of  
Adium using them, because there are too many instances at present in  
which we depend upon parsing out the strings in order to know what  
information is being passed in from libpurple.  After 2.0.0 is out  
I'm going to make up a list and look at how we can switch in at least  
those instances to passing around an enum value or an English  
identifier string so the UI can act as it wishes, but I imagine that  
this will also include a number of strings changes so I waited so far  
in order to honor the string freeze.  Maybe we should make this a  
2.0.1 goal, as well?  Or are there problems with gettext *using* the  
translations with the purple strings being in a separate binary from  
the gtk UI?

-Evan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://pidgin.im/cgi-bin/mailman/private/cabal/attachments/20070407/4ff39715/attachment.htm