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

er 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