User:Liangent/wb-lang/dev

Requirements

 * Clean up language codes first (eg zh-classical => lzh, zh-yue => yue and disable some codes)
 * User:Stevenliuyi find this table from IANA And according to my experience in Commons and wikidata, the 6 dialect language tags are very confusing. So even if the 6 dialect language tags exist, their names and tags should be changed . zh-hk => zh-hant-hk, zh-tw => zh-hant-tw, zh-cn => zh-hans-cn, zh-mo => zh-hant-mo, zh-sg => zh-hans-sg, zh-my => zh-hans-my. --fanchy (talk) 13:32, 6 June 2013 (UTC)
 * Sorry but this point was meant to keep close to MediaWiki core. ie. Language::factory('zh-classical')->getCode == 'lzh'. Maybe you can file a bug against core first and see whether they accept it, and it seems out of scope of this plan. Liangent (talk) 13:43, 6 June 2013 (UTC)
 * bug49274--fanchy (talk) 20:40, 6 June 2013 (UTC)


 * Site link table (see above)
 * Opt-out: {{#babel:en-0}}
 * Interesting idea. I am actually using -0 to say "I am interested in that language, but I don't speak it", and to switch it on, not off. Why would one want to opt-out, do you have a (not too hypothetical) use case? In the case of yes, -0 could work, I guess. --Denny (talk) 21:13, 31 May 2013 (UTC)
 * I'm reading en-0 as "I'm expected to be able to use en but actually I can't use it" - eg, {{#babel:en-N|fr-0}} on frwiki. Liangent (talk) 15:19, 2 June 2013 (UTC)

API

 * For all wbget* actions accepting &languages=:
 * When &languages=zh-cn is wanted but zh-cn is not there:
 * 
 * if there's zh-tw and en in known labels ('something' is guaranteed to be in zh-cn, by Language converter)
 * 
 * if there's only en in known labels ('something' is in English)
 * Is there a need to say for what it is the fallback language? Or could we just pass the label and that's it? --Denny (talk) 21:13, 31 May 2013 (UTC)
 * Aliases: convert-fallbacks are added, but plain fallbacks are not added
 * Aliases do not need to be regarded at all, because they are only used for expanding the search. Don't do anything with them. --Denny (talk) 21:13, 31 May 2013 (UTC)
 * For all wbset* actions:
 * Behaviors are not changed. Data set to exact language code requested by user.
 * Remember to take care of zh-classical and such (this falls out of scope of this project)
 * For action=wbsearchentities:
 * Things might be difficult and put off
 * For multilingual text values:
 * I need some real world examples to see how it works now...
 * Not implemented yet, ignore. --Denny (talk) 21:13, 31 May 2013 (UTC)
 * New API: action=(wb)userfallbackchain - returns a fully resolved user fallback info

WebUI

 * +langname comment when needed like -> (English)


 * Item label/description
 * display in user's most preferred language, prefill with display value when user starts editing, and save to user's language
 * I say both zh and en. When I have my userlang set to zh, en is displayed as fallback, I'm editing the label
 * Since I can use both zh and en, I may be misled that I'm changing the English label (especially when there's (English) nearby).
 * Good point. Will need a bit thought here. --Denny (talk) 21:13, 31 May 2013 (UTC)
 * Item aliases
 * display all aliases in userlangs explicitly listed in babel + all convert-fallbacks (no zh->en fallbacks and such)
 * new alias: added to userlang
 * removal: do we really want to remove it from fallback source? users may be deleting an alias because it's in a foreign language and not recognized by current editor :/ or make aliases from fallback readonly?
 * No, no, don't do anything for aliases. There is no need for them to fallback, or put differently, the only possible need for them to fallback is in search, but we are not touching that. --Denny (talk) 21:13, 31 May 2013 (UTC)
 * Item displayed as value of claims
 * only label in most preferred language, like the first bullet above w/o editing
 * Property suggestion
 * ditto
 * Item suggestion (as claim values)
 * ditto
 * (and any more autocomplete suggestions?)
 * New special page, corresponding to API: action=(wb)userfallbackchain, allowing users to confirm the info themselves.
 * Incorporate with the current "In other languages" section.

Client

 * How to tell {{#property: caller the language a value is in, when it's from fallback?
 * Extend syntax to accept a list of languages? Allow defining whether fallback is used or not?
 * No extension of syntax, please. The property-parserfunction is meant to be simple. Anything else can be done with Lua. Maybe it should not fall back here: In Wikidata one could make the case that fallback is useful, but once the data is being used in a Wikipedia, should it not have at least labels in that language? --Denny (talk) 21:13, 31 May 2013 (UTC)
 * Then things won't work well. For zh, almost all users must be using a variant ( = zh-cn, zh-tw etc ) and {{#property: is fetching data from zh language on zhwiki, which would be nearly empty (if zh-cn data are not populated to zh on editing...). btw conversion will be done in some parsing process after {{-transformation so we don't need to care about it here. However we need to wrap content in -{}- (LanguageConverter::markNoConversion) if data is being fetched for zh-cn (Parser::getConverterLanguage) from known zh-cn label. Liangent (talk) 09:04, 1 June 2013 (UTC)

Lua

 * TBD
 * The only thing needed in Lua is to give access to the fallback chain, if it is not already there. Then everything else can be implemented as wanted. --Denny (talk) 21:13, 31 May 2013 (UTC)
 * So something similar to action=(wb)userfallbackchain? but Lua can't do conversion in it, what if it needs that? Liangent (talk) 09:02, 1 June 2013 (UTC)

PHP

 * All places where a Language object is expected: can be an array now, eg array( Language::factory( 'zh' ), 'zh-tw', 'zh-cn' ) meaning a "convert-from-zh-tw-to-zh-cn" language?