The user language is not likely to be available in Scribunto, as it would cause cache fragmentation issues.

The ask is only to read the user language code by a value or a function getUserLanguageCode() which return "en" or "fr"... Then the module can choose the right table in its own i18n tables. Then the module can display its messages in the best language for the user or the admin who maintains the page or the module.

Bottom line: this isn't going to happen unless the feature requested in bug 2085 gets implemented, for all the reasons that feature hasn't been implemented yet.

Bumping this one to high as T158470 got closed with a comment that it should happen here.

On https://www.mediawiki.org/wiki/Extension:Wikibase_Client/Lua the user language is already offered, but always in combination with something else.
Currently things like "args.lang = frame:callParserFunction( "int", "lang" ) -- get user's chosen language" are being used to achieve this result.

IMO, it was a bad idea for {{int:}} to ever work on user language instead of on content/page/site language. I don't think we should extend that mistake.

For 2 months I use translate.init_wiki_user_page_lang() for your ask of 3 languages.
For this, central modules need T68051 and T142906.
I have also a marginal task to create:
T20170211 : in mw.language.fetchLanguageNames( 'fr' ) some languages names are not in French.
Search "versioning_tasks_report()" in Central-s-fr.

In T68051#3039233, @Jackmcbarn wrote:

IMO, it was a bad idea for {{int:}} to ever work on user language instead of on content/page/site language. I don't think we should extend that mistake.

What you're saying is that we should only display Wikimedia Commons in English. Judging from your English Wikipedia user page you're a monolingual speaker of English. So you probably don't need it, but we have many other users for which we would like to display the interface in another language.

In T68051#3041085, @Multichill wrote:

What you're saying is that we should only display Wikimedia Commons in English.

No. I just meant that a parser function is too early in the parse for internationalization to happen. I think it should happen later in the parse, like the language converter does.

We could have mw.language.getUserLanguage() with getContentLanguage() and getPageLanguage() to complete languages needs of any modules. See T161976

Is there any progress in this task?

At the moment most modules on Commons use frame:callParserFunction("int","lang") call to get users language. It is a solution that works fine on multilingual projects like Commons and Wikidata, but I am not sure if it is accessible on other projects. I assume that the purpose of this task to come up a way which is guaranteed to work on the projects.

frame:callParserFunction("int","lang") is the same as {{int:Lang}}. It is just a workaround, created by admins on projects which need this functionality. On other projects where admins did not create int:Lang message map none of these workarounds work.

Can we just use _, lang = mw.wikibase.getLabelWithLang( 'Q1' ) ? That line seems to always return the language of the viewer. I do not know if Q1 has a label for all supported languages, but if not than we can add some.

In T68051#6070113, @Jarekt wrote:

Can we just use _, lang = mw.wikibase.getLabelWithLang( 'Q1' ) ? That line seems to always return the language of the viewer. I do not know if Q1 has a label for all supported languages, but if not than we can add some.

I like this workaround! Good idea. This doesn't solve anything for wikis outside WMF wikis, but can solve much trouble with maintaining those int:Lang pages by admins on WMF wikis.

I checked and _, lang = mw.wikibase.getLabelWithLang( 'Q2' ) is a better approach, since Q2 had labels in 287 langiuages and Q1 "only" in 189. So is this an acceptable way to look up language of the user? Every template on Commons calls {{int:Lang}}, often many times per page. If we switch from lang=frame:callParserFunction("int","lang") to _, lang = mw.wikibase.getLabelWithLang( 'Q2' ) than suddenly 50M pages will be querying Q2's label. Maybe there is a better way.

suddenly 50M pages will be querying Q2's label

Yes, but only during saving an edit, so this should be ok from my perspective. I just still have doubts about whether this will work correctly.

In T68051#6079807, @Dvorapa wrote:

suddenly 50M pages will be querying Q2's label

Yes, but only during saving an edit, so this should be ok from my perspective. I just still have doubts about whether this will work correctly.

During parsing a page. Which can be every other page view. Also, this will create 50M "links" to the item in the database of Commons, so a potential performance problem.

If this way of getting the language works for you, then perhaps it could be moved to a new function to work independently of Wikidata...

In T68051#6080295, @matej_suchanek wrote:

If this way of getting the language works for you, then ...

@matej_suchanek This approach seems to work in limited test I was able to perform. Q2 has labels for 287 languages and I believe MediaWiki supports over 450, so this approach would not work for users of 160 languages, but there again those are probably the languages we do not have any content in anyway. Function mw.wikibase.getLabelWithLang does on document what the language output is. By observation it seem to be the language of the viewer, but it is unclear how many languages can be returned. Mw.language library recognizes language codes which are ValidBuiltIn, Known, or supported, It would be nice to know which set the outputs of this function fall into.

In T68051#6080295, @matej_suchanek wrote:

perhaps it could be moved to a new function to work independently of Wikidata...

A new function to work independently of Wikidata would be great. Perhaps mw.language.getUserLanguage() (aka mw.getUserLanguage()) to get "language object" with getCode() property to get the actual language code.

In T68051#6080295, @matej_suchanek wrote:

Also, this will create 50M "links" to the item in the database of Commons, so a potential performance problem.

Yes, we would like to avoid that. Once Commons SQL database have 50M links, they do not seem to ever go away. As I reported in T243602, we still have 13M links to some modules and templates which are not being used for over a year.

In T68051#6080581, @Jarekt wrote:

Function mw.wikibase.getLabelWithLang does on document what the language output is.

It says

Like mw.wikibase.getLabel, but has the language the returned label is in as an additional second return parameter.

which leads to

The label will either be in the Wiki's language (on monolingual wikis) or the user's language (on multilingual Wikis), furthermore language fallbacks will be applied

(yet another overhead)

@matej_suchanek Sorry for nit-picking but that second sentence is in documentation of mw.wikibase.getLabel function, and I did not noticed it when I was reading documentation of mw.wikibase.getLabelWithLang. There is a link to the other function, so it should not have been hard to find.

So if mw.wikibase.getLabelWithLang function returns " Wiki's language (on monolingual wikis) or the user's language (on multilingual Wikis)", we would have to decide on behavior of our hypothetical new mw.language.getUserLanguage() function on monolingual wikis. I do not have strong opinions one way or the other. In one hand If I am looking at a page in some wiki, where I do not know the language, it is nice if some parts show up in languages I know, but on the other hand other wiki's templates might not be handling such cases correctly.

There is an API to get languages users speak: https://commons.wikimedia.org//w/api.php?action=query&meta=babel&babuser=Jarekt. Maybe it would be possible to get babel preferences of the current user.

In T68051#3043946, @Jackmcbarn wrote:

I just meant that a parser function is too early in the parse for internationalization to happen. I think it should happen later in the parse, like the language converter does.

If you have a more performant idea that still offers the flexibility that translated messages can contain arbitrary wikitext, I’m all ears. It would be great to get rid of this hack that’s a nightmare from a performance viewpoint, but I’m not sure if it’s possible.