Page MenuHomePhabricator

Make docSubpage configurable
Closed, DeclinedPublic

Description

Today modules/ext.templateDataGenerator.editPage.js loads the name of the expected documentation subpage from the i18n string templatedata-doc-subpage.

This however assumes that the subpage used for documentation is only governed by language. In practice there is no reason why en.wikipedia.org, en.wikisource.org and en.weHateAbbreviations.com would all use doc as the name for their documentation subpages.

Moving this from an i18n to a config variable (with fall-back to the i18n if we want to keep that) would acknowledge the fact that not all wikis are Wikipedia.

Event Timeline

Restricted Application added a project: VisualEditor. · View Herald TranscriptApr 24 2018, 7:48 AM
Restricted Application added a project: VisualEditor. · View Herald TranscriptApr 24 2018, 6:52 PM
Deskana moved this task from To Triage to Freezer on the VisualEditor board.Apr 24 2018, 6:53 PM
Vvjjkkii renamed this task from Make docSubpage configurable to vdeaaaaaaa.Jul 1 2018, 1:14 AM
Vvjjkkii triaged this task as High priority.
Vvjjkkii updated the task description. (Show Details)
AfroThundr3007730 renamed this task from vdeaaaaaaa to Make docSubpage configurable.Jul 1 2018, 5:41 AM
AfroThundr3007730 raised the priority of this task from High to Needs Triage.
AfroThundr3007730 updated the task description. (Show Details)
Lokal_Profil updated the task description. (Show Details)Jul 5 2018, 12:44 PM

Yeah, this should really be a project-dependent variable, not language-dependent

Krinkle closed this task as Declined.Jul 14 2018, 11:10 PM
Krinkle added a subscriber: Krinkle.

@Lokal_Profil Localisation messages can be changed on a project-wide level already. This done through the MediaWiki namespace.

This is, for example, how the main namespace on English Wikipedia is is described as "Article", as "Entry" on English Wiktionary, and other English-language projects may have the default of "Page" if no local override is specified. The same applies to the name of the main page, and other such things.

I'm closing this as such, but please re-open if I misunderstood.

Lokal_Profil reopened this task as Open.Sep 14 2018, 8:32 AM

@Lokal_Profil Localisation messages can be changed on a project-wide level already. This done through the MediaWiki namespace.

This is, for example, how the main namespace on English Wikipedia is is described as "Article", as "Entry" on English Wiktionary, and other English-language projects may have the default of "Page" if no local override is specified. The same applies to the name of the main page, and other such things.

I'm closing this as such, but please re-open if I misunderstood.

Sorry for missing your response.

Yes localisation messages can be change on a per wiki level. But the variable in question isn't used for the interface (like page/article) but determines MediaWiki behaviour such as where VisualEditor expects to find TemplateData. Unlike other localisation messages it should also not be affected by the users language settings.

To clarify. I'm not saying that the current solution doesn't work I'm saying that it is conceptually wrong to see this as a language dependent variable rather than a project one. As such this should be moved from an i18n to a config variable (with fall-back to the i18n if we want to keep that as a default value).

Localisation message have two modes: content-language, or user-language.

For messages that relate to wiki configuration, we use content-language. For example, https://en.wikipedia.org/wiki/MediaWiki:Gadgets-definition and https://en.wikipedia.org/wiki/MediaWiki:Citoid-template-type-map.json are interpreted this way. No matter what language you select in preferences on English Wikipedia, these pages will be applied to the software.

For messages are are purely for the interface text and labels, the user-language is used. This means that the MediaWiki-page overrides only apply to users whom's language matches the wiki's content language, otherwise the default interface message is used from the software translation.

The /doc sub page in TemplateData is localised via templatedata-doc-subpage. This message is interpreted by the software using the content-language, not the user-language. (source code).

If you find that this isn't working, let us know! If not, could you re-close the task?

Lokal_Profil closed this task as Declined.Sep 28 2018, 9:20 AM

Thanks for the clarification