Page MenuHomePhabricator

Support for switching language variants
Closed, ResolvedPublic

Description

Since it's only a viewer I guess it's fine to just implement this as different language.


Version: Unspecified
Severity: enhancement

Details

Reference
bz32906

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 22 2014, 12:07 AM
bzimport set Reference to bz32906.
bzimport added a subscriber: Unknown Object (MLST).

Do you mean support for SWITCHING the language variant from the user interface ?

Because as far as I can tell, variants are already supported ?:
http://zh.m.wikipedia.org/zh-hk/血親
http://zh.m.wikipedia.org/zh-cn/血親

(In reply to comment #1)

Do you mean support for SWITCHING the language variant from the user interface
?

Because as far as I can tell, variants are already supported ?:
http://zh.m.wikipedia.org/zh-hk/血親
http://zh.m.wikipedia.org/zh-cn/血親

Yes without UI I can't even know there's such feature.

philinje wrote:

Both switching of app UI and inter-wiki language variations of an article are implemented. Can we close this?

What should be done for inter-wiki language variations?(In reply to comment #3)

Both switching of app UI and inter-wiki language variations of an article are
implemented. Can we close this?

What was done for inter-wiki language variations?

@Phil

App UI and interwiki are not the same as language variants.
We have a 3rd language option, and it's just for a few of the wiki's, they are called Variants. Basically it's an option to switch script for the content languages that can be transliterated into multiple scripts.

The Chinese language is one of those. You can switch between zh-cn, zh-hk, zh-sg, zh-tw, with a small drop down menu right to the Talk page tab. All are chinese, but all written differently. This option only shows and is only needed on a couple of wiki's. I think the only other language that has this option is the sr language wiki.

http://www.mediawiki.org/wiki/Language_in_MediaWiki

(In reply to comment #5)

I think the only other language that has this option is
the sr language wiki.

Also gan, iu, kk, ku, shi and tg as well.

philinje wrote:

Sounds like the list to test is sr, gan, iu, kk, ku, shi and tg

(In reply to comment #8)

Sounds like the list to test is sr, gan, iu, kk, ku, shi and tg

and zh

What we'd probably need is a couple of things:

  • MobileFrontend needs to see what language variants are available and export them in a machine-readable way (as well as some UI-accessible way for humans!)
  • PhoneGap app needs to read that data out and make it available in some sort of user interface
  • PhoneGap app needs to take the variant preference and pass it on all your URLs when actually loading (?)

May also have to consider how to properly deal with saved pages - can you save the same page in different variants? Do we include the variant link in the URLs when sharing and saving and in history?

Note that links within pages don't appear to be forced to the variant form; they're all just using /wiki/whatever from what I can see, which means unless we process the links, when navigating you'll jump back to the default setting.

philinje wrote:

removing as 1.0 blocker, assigning to 1.1 for now

philinje wrote:

*** Bug 32921 has been marked as a duplicate of this bug. ***

philinje wrote:

Bug 32921 seems related, possibly the same cause, but not sure what title conversion means

  • Bug 37582 has been marked as a duplicate of this bug. ***

Added 38101 as blocker to this feature because it requires mobilefrontend work

Looks like the system already supports passing a 'variant' parameter on the request, it's just that since it's handled internally by LanguageConverter and friends it's not documented on the API. :)

We'd still need to export them in a machine-readable way, or hardcode them in the app (easy but annoying to maintain), then make sure we have a UI for selecting it and include it in the request.

(In reply to comment #16)

Looks like the system already supports passing a 'variant' parameter on the
request, it's just that since it's handled internally by LanguageConverter and
friends it's not documented on the API. :)

We'd still need to export them in a machine-readable way, or hardcode them in
the app (easy but annoying to maintain), then make sure we have a UI for
selecting it and include it in the request.

It seems the language converter go to check $wgRequest for variant directly and it's a part of the parsing process. Does this violate the "No $wg*** in Parser" principle, or al least should be context-fied?

(In reply to comment #18)

(In reply to comment #16)

Looks like the system already supports passing a 'variant' parameter on the
request, it's just that since it's handled internally by LanguageConverter and
friends it's not documented on the API. :)

We'd still need to export them in a machine-readable way, or hardcode them in
the app (easy but annoying to maintain), then make sure we have a UI for
selecting it and include it in the request.

It seems the language converter go to check $wgRequest for variant directly and
it's a part of the parsing process. Does this violate the "No $wg*** in Parser"
principle, or al least should be context-fied?

As far as I can see the variant code doesn't use any request data in the parser context.

(In reply to comment #19)

(In reply to comment #18)

(In reply to comment #16)

Looks like the system already supports passing a 'variant' parameter on the
request, it's just that since it's handled internally by LanguageConverter and
friends it's not documented on the API. :)

We'd still need to export them in a machine-readable way, or hardcode them in
the app (easy but annoying to maintain), then make sure we have a UI for
selecting it and include it in the request.

It seems the language converter go to check $wgRequest for variant directly and
it's a part of the parsing process. Does this violate the "No $wg*** in Parser"
principle, or al least should be context-fied?

As far as I can see the variant code doesn't use any request data in the parser
context.

Some functions parser calls as a part of parsing do global $wgRequest.

(In reply to comment #20)

Some functions parser calls as a part of parsing do global $wgRequest.

To clarify:

Parser::parse() calls Language::convert() in line 414.
which calls LanguageConverter::convert() in line 3537.
which calls LanguageConverter::getPreferredVariant() in line 605.
which does global $wgUser, *and* calls LanguageConverter::getURLVariant() and LanguageConverter::getHeaderVariant() in line 163 and line 168.
which do global $wgRequest.

Ah... crap, right. Missed examining convert.

Yes, it's a terrible abstraction violation worthy of great headdesks. :) But... it works for now, and documenting it means we can use it and can worry about refactoring the guts later and replacing the implicit 'variant' parameter with an explicit one that gets passed into the ParserOptions object cleanly.

(In reply to comment #23)

Yes, it's a terrible abstraction violation worthy of great headdesks. :) But...
it works for now, and documenting it means we can use it and can worry about
refactoring the guts later and replacing the implicit 'variant' parameter with
an explicit one that gets passed into the ParserOptions object cleanly.

But refactoring may mean that we need to fix parser callers, and it may trash our work we do now attempting to use the implicit "variant" parameter.

Right; then make it explicit when doing that refactoring.

Bonus points for devising unit tests. :)

Filing a separate bug for variant support in action=mobileview: bug 41995. Titles and section names need to be converted, which currently are not.

(In reply to comment #25)

Right; then make it explicit when doing that refactoring.

Bonus points for devising unit tests. :)

OK one case came just now: some user reports bug 42002. With this implicit parameter we can just let TimedText:XXX.LANG.srt have page language = LANG, then pass in a variant=XX parameter (because we're using api.php?action=parse) but what if the parameter goes away?

btw. after the fix we should really let action=parse accept a explicit "variant" parameter.

This is planned for the new app.

Dbrant claimed this task.