User:Liangent/wb-lang/dev

From MediaWiki.org
Jump to navigation Jump to search

Notes[edit]

  • Reverse fallback: en doesn't fall back to en-GB (instead, en-GB falls back to en), but en-GB contents might be useful for en readers too (though we can ask en users to add en-GB to their user fallback, but that's not that friendly. Also this doesn't work on site contents.
    • If someone enters en-gb but not en, that's just trolling :) - I wouldn't do anything about that. On the other hand, we could maybe think about adding en-gb to en as a fallback... but that might be a longer discussion with others. --Denny (talk) 14:19, 31 May 2013 (UTC)
      • Someone mentioned (sorry I forgot his/her name) people from British IP may be suggested by the system to use en-gb as their language, and labels they input are left in en-gb... Liangent (talk) 14:26, 31 May 2013 (UTC)

  • There may need to be a third type of fallback: zh-mo-taken-from-zh-hk without conversion...
    • Need to change LanguageWithConversion (+rename? candidate: LanguageFallbackChainItem ? ) FallbackChainFactory (to create them from getVariantFallback) Special:MyLanguageFallbackChain FallbackChainSerializer + their tests and no more
    • Public interfaces of LanguageWithConversion are only getFetchLanguage, getLanguage and translate + prepareForTranslate.
    • Chain interfaces are extractPreferredValue[OrAny]

Next steps[edit]

  • 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...

Yes Done

  • Adapt EntityView

Requirements[edit]

API[edit]

  • For all wbget* actions accepting &languages=:

    • When &languages=zh-cn is wanted but zh-cn is not there:
    • <label language="zh-cn" value="something" convertedfrom="zh-tw" />
      • if there's zh-tw and en in known labels ('something' is guaranteed to be in zh-cn, by Language converter)
    • <label language="en" value="something" fallbackfor="zh-cn" />
      • 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[edit]

+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[edit]

  • 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)
    • Reverse match: given there's a zh-tw label on a property, writing {{#property:<translated zh-cn label>| }} should be able to find it.

Lua[edit]

  • 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[edit]

  • 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? gerrit:67453
  • fallback chain resolver: Utils::getLanguageFallbackChain() gerrit:70871