User:Liangent/wb-lang/dev
< User:Liangent | wb-lang
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.
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 morePublic 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...
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" />Aliases: convert-fallbacks are added, but plain fallbacks are not added- 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 offReally 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:
New API: action=(wb)userfallbackchain - returns a fully resolved user fallback infoAlready 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
- 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?
- 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)
- gerrit:71072. Liangent (talk) 16:48, 28 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.
- Extend syntax to accept a list of languages? Allow defining whether fallback is used or not?
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