Last modified: 2014-03-26 01:48:29 UTC
The toolserver provides the following table: mysql> describe language; +--------------+--------------+------+-----+---------+-------+ | Field | Type | Null | Key | Default | Extra | +--------------+--------------+------+-----+---------+-------+ | lang | varchar(16) | NO | PRI | NULL | | | english_name | varchar(255) | YES | | NULL | | | native_name | varchar(255) | YES | | NULL | | +--------------+--------------+------+-----+---------+-------+ mysql> select * from language order by rand() limit 10; +------+--------------+------------------+ | lang | english_name | native_name | +------+--------------+------------------+ | cjp | Cabécar | NULL | | kks | Giiwo | NULL | | mqc | Mangole | NULL | | gby | Gbari | NULL | | kw | Cornish | Kernewek | | na | Nauruan | Ekakairũ Naoero | | ymd | Muda | NULL | | npa | Nar Phu | NULL | | waa | Walla Walla | NULL | | hss | Harsusi | NULL | +------+--------------+------------------+ 10 rows in set (0.00 sec) This could also be integrated with meta_p.wiki, by providing a 'language' and 'native_language' column.
What's the use case?
To be able to present a choice 'English/Dutch/German' or 'English/Nederlands/Duits' instead of 'en/nl/de' (for instance, having two select boxes, one for project and one for language, to select the site to run a query on).
I'm in general hesitant to include tables of data in the replicas which are simply static copies of data found elsewhere (joins in the database are much, /much/ less efficient than simply looking the data up through a hash/associative array in the application). In this particular case, a database table would almost certainly not suffice anyways: showing a language name /in that language/ is a hard problem that also necessitates fonts, RTL support, and a number of other tricks to get right. What I'd be in favour of is to find a good way to make the ULS available to tools as a reusable component instead: https://www.mediawiki.org/wiki/Universal_Language_Selector This would solve the problem neatly.
(In reply to comment #3) > What I'd be in favour of is to find a good way to make the ULS available to > tools as a reusable component instead: > > https://www.mediawiki.org/wiki/Universal_Language_Selector This seems reasonable to me. Is there a bug about making ULS reusable?
I don't think there is, but it seems to me to be valuable enough a component that spinning it off would be worthwhile in itself. I'll bring the matter up with the Language Engineering team, and try to get a better idea of what work would be needed to do that.
Adding Santhosh to Cc per Siebrand's suggestion. He also pointed me at: http://thottingal.in/projects/js/jquery.uls/examples/ So I expect the answer is "should be simple enough" or even "only needs documentation." :-)
(In reply to comment #4) > This seems reasonable to me. Is there a bug about making ULS reusable? There doesn't have to be. See https://github.com/wikimedia/jquery.uls
@Merlijn: is this a satisfactorily alternative solution?
We don't have a reasonable 'there is already a better solution available' resolution, so marking fixed.
