On Fri, Sep 19, 2008 at 3:24 PM, Sayamindu Dasgupta <[EMAIL PROTECTED]> wrote: > Yeah - I'm looking at the way this is done ib Ubuntu, and I think this > can work for us as well. Will we have support for installing extra > RPMs via the customization key in 9.1 ?
Rough notes: (some of this is from http://wiki.laptop.org/go/9.1.0#Suggestions_from_User:CScott) * translation system should look in local, then activity, then system translation tables, then repeat for each in a set of fallback languages (eg, quechua, spanish, english) * separable translation packs * wiki-like editing of translatable labels in the UI Switch to sugar.gettext module, with this extended lookup process for message strings. Switch to sugar.Label gui element, which automatically supports editing yr local translations? Expose local "dictionary" in the journal, so that "Uploading/merging" can be a separate program. (String edit should happen in a separate program's window -- communicate over dbus? -- to facilitate editing of transient strings. API should be, L("gettext msgid w/ formatting", *args), so that gettext can be taught about L(...) as a msg marker. Variants to support alternate domains and contexts. N_ variant probably not needed. OR: sugar.Label(N_('message id %s'), *args, **gettextkwds) yes, that's better. think hard about ngettext; probably kwargs like 'plural=N_('plural string'), count=n', but gettext needs to know. (this label will also support the below) Language change in the frame; on-the-fly change language in all open apps. --scott -- ( http://cscott.net/ ) _______________________________________________ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar