Since it's only a viewer I guess it's fine to just implement this as different language.
Version: Unspecified
Severity: enhancement
Since it's only a viewer I guess it's fine to just implement this as different language.
Version: Unspecified
Severity: enhancement
Status | Subtype | Assigned | Task | ||
---|---|---|---|---|---|
Resolved | None | T33805 Wikipedia Android App 1.1 tracking - current bugs | |||
Resolved | None | T35802 Wikipedia Android app retains GPS access even when it doesn't need it | |||
Resolved | • brion | T35208 Switch "near me" from Google Maps Android API to HTML-based OpenStreetMap backend | |||
Invalid | None | T35855 Wikipedia Android App potential features (tracking) | |||
Resolved | Dbrant | T34906 Support for switching language variants | |||
Resolved | None | T40101 Support switching content language variants | |||
Resolved | MaxSem | T43995 action=mobileview doesn't convert page title, section names to language variants | |||
Duplicate | None | T44240 LanguageConverter should not inspect global state to determine the variant |
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.
(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.
(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:
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:
Bug 32921 seems related, possibly the same cause, but not sure what title conversion means
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.
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.