Open hugolpz opened 2 years ago
For a Swedish speaking user, if you want to get the definitions from https://sv.wiktionary.org/wiki/lapin#Franska and similar page, then :
"si-overlay-coreContent-right-wikt-iso": "sv"
"si-overlay-coreContent-right-wikt-section-id": "#Franska"
If you prefer your community to use https://en.wiktionary.org/wiki/lapin#French :
"si-overlay-coreContent-right-wikt-iso": "en"
"si-overlay-coreContent-right-wikt-section-id": "#French"
But this system is still under construction so I may have to think to something more intuitive.
See also :
Add-on handles several languages parameters :
signLanguage
relevantWiktionary
, source for the definitions, to be readable by the user.relevantWiktinarySection
= source for the definitions, the language of the written words clicked, written inuiLanguage
(complexity therefore exploding).uiLanguage
Question
Is the relevant Wiktionary relevant to that sign language or to the add-on's user's language ?
signLanguage
As for
uiLanguage
, we currently store the following info :We could store
parentLanguage: [ 'ru', 'kh' ]
so to support languages such as Russian-Kazakh Sign Language.uiLanguage
As for
uiLanguage
, we currently store the following info :See also this WDQS query.
Complexity arise
Spanish user studying American Sign Language, may want:
Hindi user studying American Sign Language, will want:
Policy needed
Must think about a better balance between hard coded data and ../i18n/
Seems logical to assume the learner of American Sign Language knows to read in ENGLISH, and entry to ASL must go via this parent language.
See also
About "Add language UI in settings": Consider https://github.com/wikimedia/jquery.uls .