Last modified: 2012-06-19 08:06:07 UTC
So that language names can be rendered as appropriate in all circumstances.
Please provide some use cases that are not yet supported by extension CLDR.
The use case is being able to display the name of a language in a particular language. e.g. in an article (content language), or in the interface (interlanguage sidebar, bug 37703, user language). I found out just now that a hook for this exists (LanguageGetTranslatedLanguageNames), but it doesn't do anything by default. Without an extension ("Extension:CLDR", I presume) it doesn't do anything. So unless that is merged in core, we can't use it to (for example): * render language names in the sidebar in the user language * use it from wikitext to display language names in the content language If for some reason it must not be merged in core, we could maybe create an extension that depends on CLDR and implements the above 2 features?
Also, although there is a large amount of content there, it seems the list in CLDR is still somewhat incomplete: https://gerrit.wikimedia.org/r/gitweb?p=mediawiki/extensions/cldr.git;a=tree;f=LocalNames;h=97bb656aaec4ad1baaebd03e3d423ddddc7d35cf;hb=HEAD Is that upstream cldr or maintained at translatewiki?
(In reply to comment #2) > The use case is being able to display the name of a language in a particular > language. > > e.g. in an article (content language), or in the interface (interlanguage > sidebar, bug 37703, user language). > > I found out just now that a hook for this exists > (LanguageGetTranslatedLanguageNames), but it doesn't do anything by default. > Without an extension ("Extension:CLDR", I presume) it doesn't do anything. So > unless that is merged in core, we can't use it to (for example): > * render language names in the sidebar in the user language > * use it from wikitext to display language names in the content language > > If for some reason it must not be merged in core, we could maybe create an > extension that depends on CLDR and implements the above 2 features? IIRC you can just call the core methods, and if CLDR or similar is installed, it will try to provide a localised name; if that's not available it will do as it's always done. Having it in core is not a requirement, you just need to update the way that interlanguage link language names are resolved. WFM, I think. (In reply to comment #3) > Also, although there is a large amount of content there, it seems the list in > CLDR is still somewhat incomplete: > > https://gerrit.wikimedia.org/r/gitweb?p=mediawiki/extensions/cldr.git;a=tree;f=LocalNames;h=97bb656aaec4ad1baaebd03e3d423ddddc7d35cf;hb=HEAD > > Is that upstream cldr or maintained at translatewiki? Upstream. And that's what it will remain as long as translatewiki.net cannot be a bulk data supplier for Unicode's CLDR. This is the type of duplication I don not believe in.
(In reply to comment #4) > (In reply to comment #2) > > The use case is being able to display the name of a language in a particular > > language. > > > > e.g. in an article (content language), or in the interface (interlanguage > > sidebar, bug 37703, user language). > > > > I found out just now that a hook for this exists > > (LanguageGetTranslatedLanguageNames), but it doesn't do anything by default. > > Without an extension ("Extension:CLDR", I presume) it doesn't do anything. So > > unless that is merged in core, we can't use it to (for example): > > * render language names in the sidebar in the user language > > * use it from wikitext to display language names in the content language > > > > If for some reason it must not be merged in core, we could maybe create an > > extension that depends on CLDR and implements the above 2 features? > > IIRC you can just call the core methods, and if CLDR or similar is installed, > it will try to provide a localised name; if that's not available it will do as > it's always done. Having it in core is not a requirement, you just need to > update the way that interlanguage link language names are resolved. WFM, I > think. > Great. So bug 37703 will be easy to solve (maybe you can give a pointer there on how to trigger mediawiki core to return the localized name if available, and fallback to name in language itself). This bug is WORKSFORME indeed. The solution is to use the LanguageGetTranslatedLanguageNames hook. And the easiest way to do that is to install the CLDR extension. Thanks! > (In reply to comment #3) > > Also, although there is a large amount of content there, it seems the list in > > CLDR is still somewhat incomplete: > > > > https://gerrit.wikimedia.org/r/gitweb?p=mediawiki/extensions/cldr.git;a=tree;f=LocalNames;h=97bb656aaec4ad1baaebd03e3d423ddddc7d35cf;hb=HEAD > > > > Is that upstream cldr or maintained at translatewiki? > > Upstream. And that's what it will remain as long as translatewiki.net cannot be > a bulk data supplier for Unicode's CLDR. This is the type of duplication I don > not believe in. Keeping it upstream sounds good, but maybe translatewiki could organize a one-off (maybe repeat it a few years later) collaboration to get more in CLDR? Or maybe CLDR has a contribution proces that members of translatewiki.net could be pointed to to contribute?
(In reply to comment #5) > So bug 37703 will be easy to solve (maybe you can give a pointer there > on how to trigger mediawiki core to return the localized name if available, and > fallback to name in language itself). Leaving this for someone else to reply. IANAD :). I'm just happy to know roughly what possible and available... There are some social issues to consider before you might do this. People (read: experienced editors) are so very used to the way MediaWiki works that a very visible change like this will get some backfire. I'm looking for a real benefit here, and I'm not seeing it yet. > Keeping it upstream sounds good, but maybe translatewiki could organize a > one-off (maybe repeat it a few years later) collaboration to get more in CLDR? > Or maybe CLDR has a contribution proces that members of translatewiki.net could > be pointed to to contribute? That would be [[translatewiki:CLDR]].
