It may be a good idea, however, to adapt it for mobile devices better: to make it smaller and easier to load without the less necessary parts.

The database is pretty much as small as it gets, it's just one file. Easy to process automatically.

, but creating more databases of RTL language

Just a clarification - we're currently considering a JavaScript array not a database and hoping to put this in core. We think this is super simple code e.g.

Basically something like this:

// possible config value: ['he'];
function isRTL(lang) { return mw.config.get('wgLanguagesRTL') .indexOf(lang) > -1; }

I'd love some guidance on what you'd recommend here with this approach. We are hoping to work on this soon!

How is wgLanguagesRTL defined? My worry is that we are creating a yet another place that needs to be updated when a new language is added (and which we inevitably forget to update at some point).

In T189036#4031080, @Nikerabbit wrote:

How is wgLanguagesRTL defined? My worry is that we are creating a yet another place that needs to be updated when a new language is added (and which we inevitably forget to update at some point).

My point exactly.

In T189036#4030362, @Jdlrobson wrote:

, but creating more databases of RTL language

Just a clarification - we're currently considering a JavaScript array not a database and hoping to put this in core. We think this is super simple code e.g.

Of course; ULS langdb is not an SQL database either, it's just a YAML file, with a JSON version, and a bunch of JS functions for easy querying.

If you render the languages server-side, you should use the PHP functions in Language.php, and not ULS. (Although I hope to merge them some day, too.)

If you do it on the client side, you should load the language-data library, a.k.a. langdb. It is already available for MediaWiki as part of ULS, although I don't know how easy is it for MobileFrontend to load it.

If you do it on the client side, you should load the language-data library, a.k.a. langdb. It is already available for MediaWiki as part of ULS, although I don't know how easy is it for MobileFrontend to load it.

MobileFrontend cannot depend on ULS so whatever we will need to do should be in core, so that's a non-starter.

If you render the languages server-side, you should use the PHP functions in Language.php, and not ULS. (Although I hope to merge them some day, too.)

I tried this approach here: https://gerrit.wikimedia.org/r/#/c/415176/2 but there are concerns about performance

How is wgLanguagesRTL defined? My worry is that we are creating a yet another place that needs to be updated when a new language is added (and which we inevitably forget to update at some point).

That's what I'm asking for guidance on :)
According to the conversation on https://gerrit.wikimedia.org/r/#/c/415187/, the best proposal there seems to be to have a maintenance script that generates a php file. I would appreciate your help/advice/experience/review on doing that... if you don't like it, by all means please suggest a better way to do the same thing. The end goal would be exposing this information inside langlinks API in the cheapest possible way.

I think the title for this bug doesn't reflect the patch I'm working on in https://gerrit.wikimedia.org/r/#/c/415187/ - the goal is not to use the database for this kind of lookup and for the code to live in core (MobileFrontend will not use ULS)
I'm going to push ahead with the static array in the mean time.

Thanks for the update. Can you point me to the library in core so I can update this ticket?

It's in GitHub: https://github.com/wikimedia/language-data/

I'm not really sure what's being asked of my team here. The npm module you point to could be used in MobileFrontend but it leads to a considerable and unacceptable increase in bundle size from 1.9kb to 14.15KB

Patch:

Existing code:
https://github.com/wikimedia/mediawiki-extensions-MobileFrontend/blob/master/src/mobile.languages.structured/rtlLanguages.js

I agree the array in the link above in MobileFrontend shouldn't exist, but it only exists because the information is not provided by the API response it queries. What is needed from my perspective is an update to the meta=languageinfo API to return an isRTL property in the responses for each language which is RTL so we can drop this code from MobileFrontend entirely and rely on the API response. This solution doesn't help viable to me as written.

T190129: Consolidate language metadata into a 'language-data' library and use in MediaWiki ought to make this better by providing this data in core through normal interfaces.

For language supported in MediaWiki, this information is available through Language::isRTL. It is rather slow to go through all languages, so some kind of caching is probably useful to keep such a list automatically up to date while not having performance impact.