Last modified: 2013-10-30 00:01:57 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 32906 - Support for switching language variants
Support for switching language variants
Status: NEW
Product: Wikipedia App
Classification: Unclassified
Generic (Other open bugs)
Unspecified
All All
: Normal enhancement
: ---
Assigned To: Nobody - You can work on this!
:
: 32921 37582 (view as bug list)
Depends on: 42240 38101 41995
Blocks: 33855
  Show dependency treegraph
 
Reported: 2011-12-09 16:50 UTC by Liangent
Modified: 2013-10-30 00:01 UTC (History)
8 users (show)

See Also:
Web browser: ---
Mobile Platform: Android
Assignee Huggle Beta Tester: ---


Attachments

Description Liangent 2011-12-09 16:50:57 UTC
Since it's only a viewer I guess it's fine to just implement this as different language.
Comment 1 Derk-Jan Hartman 2011-12-09 21:59:25 UTC
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/血親
Comment 2 Liangent 2011-12-10 06:01:12 UTC
(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.
Comment 3 Phil Chang 2011-12-15 21:53:15 UTC
Both switching of app UI and inter-wiki language variations of an article are implemented. Can we close this?
Comment 4 Liangent 2011-12-16 09:47:38 UTC
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?
Comment 5 Derk-Jan Hartman 2011-12-19 08:33:32 UTC
@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
Comment 6 Liangent 2011-12-19 14:11:24 UTC
(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.
Comment 7 Tomasz Finc 2012-01-03 19:28:39 UTC
This also affects Serbian.
Comment 8 Phil Chang 2012-01-03 23:34:32 UTC
Sounds like the list to test is sr, gan, iu, kk, ku, shi and tg
Comment 9 Liangent 2012-01-04 04:42:55 UTC
(In reply to comment #8)
> Sounds like the list to test is sr, gan, iu, kk, ku, shi and tg

and zh
Comment 10 Brion Vibber 2012-01-04 18:26:00 UTC
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.
Comment 11 Phil Chang 2012-01-04 18:31:46 UTC
removing as 1.0 blocker, assigning to 1.1 for now
Comment 12 Phil Chang 2012-01-26 01:20:48 UTC
*** Bug 32921 has been marked as a duplicate of this bug. ***
Comment 13 Phil Chang 2012-01-26 01:21:53 UTC
Bug 32921 seems related, possibly the same cause, but not sure what title conversion means
Comment 14 Derk-Jan Hartman 2012-07-01 13:41:17 UTC
*** Bug 37582 has been marked as a duplicate of this bug. ***
Comment 15 Derk-Jan Hartman 2012-07-01 13:47:20 UTC
Added 38101 as blocker to this feature because it requires mobilefrontend work
Comment 16 Brion Vibber 2012-11-10 13:16:48 UTC
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.
Comment 17 Brion Vibber 2012-11-10 13:17:04 UTC
Doc for 'variant' on action=mobileview: https://gerrit.wikimedia.org/r/32718
Comment 18 Liangent 2012-11-10 16:31:29 UTC
(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?
Comment 19 Daniel Friesen 2012-11-10 17:41:26 UTC
(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.
Comment 20 Liangent 2012-11-10 17:53:22 UTC
(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.
Comment 21 Liangent 2012-11-10 18:00:55 UTC
(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.
Comment 22 Daniel Friesen 2012-11-10 18:09:04 UTC
Ah... crap, right. Missed examining convert.
Comment 23 Brion Vibber 2012-11-10 18:15:27 UTC
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.
Comment 24 Liangent 2012-11-10 18:19:42 UTC
(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.
Comment 25 Brion Vibber 2012-11-10 18:25:15 UTC
Right; then make it explicit when doing that refactoring.

Bonus points for devising unit tests. :)
Comment 26 Brion Vibber 2012-11-11 04:16:53 UTC
Filing a separate bug for variant support in action=mobileview: bug 41995. Titles and section names need to be converted, which currently are not.
Comment 27 Brion Vibber 2012-11-11 04:20:51 UTC
Work in progress in 'variants' branch on my clone:

https://github.com/brion/Wikipedia/commits/variants
Comment 28 Liangent 2012-11-11 08:52:43 UTC
(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.
Comment 29 Brion Vibber 2013-10-30 00:01:57 UTC
This is planned for the new app.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links