Page MenuHomePhabricator

Scribunto console is in English instead of the site language
Open, Needs TriagePublic

Description

The Scribunto debugging console (when you edit module, under the edit window) runs in English instead of the site language.

So when you have (trivial artificial example) module "January" on cs wiki containing eg.:

local module = {
  plain = mw.message.new( "january" ):plain()
}
return module

then calling

j = require( "Module:January" )
-- some other code
print( j.plain )

will print leden while calling

print( p.plain )

in debug console will print January

Event Timeline

Danny_B created this task.Feb 9 2016, 6:04 AM
Danny_B raised the priority of this task from to Medium.
Danny_B updated the task description. (Show Details)
Danny_B added subscribers: Danny_B, Anomie, tstarling.
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptFeb 9 2016, 6:04 AM
Aklapper raised the priority of this task from Medium to Needs Triage.Feb 9 2016, 10:23 AM
Aklapper added a project: I18n.
Aklapper set Security to None.
Restricted Application added a subscriber: StudiesWorld. · View Herald TranscriptFeb 9 2016, 10:23 AM
Anomie closed this task as Invalid.Feb 9 2016, 3:28 PM
Anomie claimed this task.

Scribunto's mw.message module uses the page language as the default, as that is likely to be the most useful default in whatever context the module is being used.

In the console, the current page is the module itself.[3] And the default page language for all Module pages is English rather than the site language, since (like most programming languages[1]) Lua itself uses English keywords, generally uses ASCII for identifiers,[2] and so is usually best displayed left-to-right.

[1]: See enwiki's article on non-English-based programming languages for some discussion on that topic.
[2]: Lua 5.1 is a bit confusing in that its definition of "letter" can be affected by the locale, but ASCII would always be safe to use.
[3]: Although it's possible to force the console to appear on other pages if you want with something like $( '<div>', { id: 'mw-scribunto-console' } ).insertAfter( '#wpTextbox1' ); mw.loader.load( 'ext.scribunto.edit' );, in which case it will use that page's language as expected.

Danny_B reopened this task as Open.Feb 9 2016, 6:45 PM

Scribunto's mw.message module uses the page language as the default, as that is likely to be the most useful default in whatever context the module is being used.
In the console, the current page is the module itself.[3]
[3]: Although it's possible to force the console to appear on other pages if you want with something like $( '<div>', { id: 'mw-scribunto-console' } ).insertAfter( '#wpTextbox1' ); mw.loader.load( 'ext.scribunto.edit' );, in which case it will use that page's language as expected.

...which does not help, because having the console in other namespace won't load the source code from edit window, thus is impossible to use the pre-defined p variable for module exports, ergo it is not possible to debug scripts using mw.message without saving them.

While I agree with the obvious statement about English in programming languages (which was actually not necessary to write here), it still does not change anything on the core of this issue which is that you can not properly debug modules using mw.message (either directly in them or used via requiring other module) in console which makes the console useless for these cases.

Suggestions:

  • have an input/select by the console to set up the language for such console session
  • introduce some global command, eg. setlang(), which called at the beginning of the script written in the console would set the lang for such session
  • assuming the preference for that wouldn't be welcomed due to the recent mode of less preferences, but it is a valid solution too
  • other way how to enforce the language for such debugging session

Actually console loads the content on non-module page too, but mw.dumpObject( p ) dumps the edit window content as a plaintext string.

In any case, it is completely user unfriendly to force user to hack the page with JavaScript manipulation to enable (if even possible, currently it seems that no as shown above) proper debugging.

Anomie removed Anomie as the assignee of this task.Dec 29 2016, 3:22 AM

Stumbled across this problem when I tried to load localised data from a Data Table on Commons and in the console I never got the data I expected to get. I agree that the current state is not at all user-friendly.