Page MenuHomePhabricator

support hundreds of languages, not just a handful
Closed, ResolvedPublic

Description

We have content modelling and ux issues that need to addressed as part of our onboarding to translatewiki. Translatewiki currently supports (eg. they have volunteers for translation) more than 200 languages, with a current technical limit of more than 500 languages. To get my head wrapped around this, I naively dumped in the whole list of technically possible languages and watched twlight lie down on the floor and not get back up.

Models:
For our partner and collection models, each additional language option results in additional database columns. Having hundreds of db columns has lots of consequences that I would collectively describe as a garbage fire. I'm working on a major rethink of those content models.

UI:
Our old problem of getting presented with a dumb list with hundreds of things in it comes back, albeit in a different form. The language preference form now has a much longer list of things in it, although we're at least automatically setting that value on first login. (hurray for sensible defaults!) The partner/collection description admin pages have become unusable, as there are now hundreds of text area elements to scroll through.

As suggested by @Nikerabbit, I'm currently experimenting with integrating wikimedia's Universal Language Selector, as it is an excellent existing solution to this particular ui challenge. It requires javascript, so we'll want to keep the large forms as a fallback.

Event Timeline

For the model issue, it sounds like we'll pull the descriptions and related fields out of the database and stick them either into templates or into a separate repo. Basically, get those things into code.

jsn.sherman triaged this task as Medium priority.Jan 8 2018, 6:11 PM
Samwalton9-WMF moved this task from Doing to Done on the Library-Card-Platform board.