Last modified: 2013-10-30 00:01:57 UTC
Since it's only a viewer I guess it's fine to just implement this as different language.
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.
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.
This also affects Serbian.
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.
removing as 1.0 blocker, assigning to 1.1 for now
*** Bug 32921 has been marked as a duplicate of this bug. ***
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.
Doc for 'variant' on action=mobileview: https://gerrit.wikimedia.org/r/32718
(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.
Work in progress in 'variants' branch on my clone: https://github.com/brion/Wikipedia/commits/variants
(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.
