User:Liangent/wb-lang/dev

Next steps
✅
 * Have LanguageWithConversion accept language code instead of language object to reduce the cost of Language initialization...
 * May need to copy some code from class Language though...
 * Adapt EntityView

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)
 * Accept a new contextlanguage={json-serialized-form-of-fallback-chain}
 * Value will be put in qqc too.
 * For action=wbsearchentities:
 * Things might be difficult and put off Really needed for user input?
 * However... it's current format doesn't do well to provide much info... eg language and sourcelanguage. I have to extend it first.
 * 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 Already embedded in JS variables

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)
 * Hmm so variant aliases are still useful for searching. Liangent (talk) 08:21, 14 June 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)
 * 71072. Liangent (talk) 16:48, 28 June 2013 (UTC)
 * Reverse match: given there's a zh-tw label on a property, writing {{#property:| }} should be able to find it.

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)
 * ... also, mw.wikibase.getEntity doesn't accept an ID, so I can't get labels in another language if mw.wikibase.label( id ) doesn't do fallback itself... Liangent (talk) 10:58, 14 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?
 * class LanguageWrapper / ExtendedLanguage / LanguageWithFallback or something? 67453
 * fallback chain resolver: Utils::getLanguageFallbackChain 70871