Page MenuHomePhabricator

Tool Labs: Provide a meta database table to replace "toolserver.language"
Closed, ResolvedPublic

Description

The toolserver provides the following table:

mysql> describe language;
+--------------+--------------+------+-----+---------+-------+

FieldTypeNullKeyDefaultExtra

+--------------+--------------+------+-----+---------+-------+

langvarchar(16)NOPRINULL
english_namevarchar(255)YESNULL
native_namevarchar(255)YESNULL

+--------------+--------------+------+-----+---------+-------+

mysql> select * from language order by rand() limit 10;
+------+--------------+------------------+

langenglish_namenative_name

+------+--------------+------------------+

cjpCabécarNULL
kksGiiwoNULL
mqcMangoleNULL
gbyGbariNULL
kwCornishKernewek
naNauruanEkakairũ Naoero
ymdMudaNULL
npaNar PhuNULL
waaWalla WallaNULL
hssHarsusiNULL

+------+--------------+------------------+
10 rows in set (0.00 sec)

This could also be integrated with meta_p.wiki, by providing a 'language' and 'native_language' column.


Version: unspecified
Severity: normal

Details

Reference
bz58792

Event Timeline

bzimport raised the priority of this task from to Needs Triage.Nov 22 2014, 2:15 AM
bzimport added a project: Toolforge.
bzimport set Reference to bz58792.

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.