On 11-09-26 03:09 PM, Brion Vibber wrote:
On Mon, Sep 26, 2011 at 2:49 PM, Happy Melon happy.melon.wiki@gmail.comwrote:
LanguageConverter would be a bitch to move out only because there are
precious few people who could tell us how it's *supposed* to work, let alone whether it still works after we change anything in it. But LC doesn't AFAIK form any sort of 'infrastructure': it's a bolt-on module that's rightly disabled most places because it requires compiled binaries.
Per IRC the 'compiled binaries' apparently referred to the Chinese conversion-table-generation code in includes/zhtable -- which is used only to freshly rebuild the conversion tables elsewhere in the source.
First, no binaries need be compiled for use of the conversion; it is completely unlike the Math situation.
Second, it's not as monolithic as you think. :) There are implementations of LanguageConverter for several different languages, each of which has to provide mapping tables etc:
gan (Gan Chinese) iu (Inuktitut) kk (Kazakh) ku (Kurdish) shi (Tachelhit) sr (Serbian) tg (Tagalog) zh (Han Chinese)
These are mostly bundled in the language classes; Chinese puts the tables in separate files due to size and just has its code in the language class file.
Basically, if you were to run a wiki *at all* in Chinese, Serbian, Kurdish, Tagalog, Inuktitut, Tachelhit, etc -- you'd probably want to do it with the conversion support.
So, there's a base class which is a dependency for languages shipped with core (such as Chinese, a fairly widely-spoken language ;) and the various languages extend those base classes and bundle their own data.
In a hypothetically more modular layout you might then have something like:
LanguageConverter is its own module
- provides LanguageConverter class
LanguageZh is its own module
- depends on LanguageConverter class
- provides ZhLanguageConverter class
- provides data sources for ZhLanguageConverter
- provides LanguageZh class
- provies zh messages
and any install that includes Chinese, Serbian, Kurdish, Tagalog, Inuktitut, Tachelhit, etc would then in some way trigger the LanguageConverter dependency and install both modules.
This is same kind of dependency structure might be nice for the Narayam input method editor -- for languages that frequently don't have native OS support it can be very nice to bundle the IME along with the language support.
-- brion
Just an interesting site note on LanguageConverter.
We actually have a bug open for adding a LanguageConverter that'll convert between en-US/en-GB... maybe even en-CA/en-AU hopefully. https://bugzilla.wikimedia.org/show_bug.cgi?id=31015
If that bug gets implemented... well then, "disabled in most places" becomes "enabled just short of everywhere"...
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]