equazcion wrote:

Correction: These language codes are incorrect in my original post, according to the interwiki link attributes: Tarantino = roa-tara, Buryat = bxr.

And just for the sake of completeness, the bug I referenced: bug 5231

These codes are not (yet) present in CLDR, so translations cannot be displayed. Wikimedia uses some non-compliant ISO codes, and even has wikis for languages codes that do not exist (anymore). Those can never be supported.

As this feature depends on third party data, I suggest we WONTFIX it here. As data becomes available, the feature will become more complete, but it will almost certainly never be complete.

Would specific upstream tickets in http://unicode.org/cldr/trac be feasible?

(In reply to comment #3)

Would specific upstream tickets in http://unicode.org/cldr/trac be feasible?

Probably only if that would include a commitment to add (and possibly maintain) the data needed for a locale for those language codes. In that sense, this issue would become a catch all bug, because the number of supported language[ code]s in Wikimedia will keep increasing.

equazcion wrote:

If we use some codes that will never exist in the external data, wouldn't it make sense to just hard-code those here?

(In reply to comment #5)

If we use some codes that will never exist in the external data, wouldn't it
make sense to just hard-code those here?

Then it would no longer be a data-driven flexible approach. That would not make sense. We have data that fails now; at some point in time, some missing data will be added, and when it does, all the better.

equazcion wrote:

(In reply to comment #6)

(In reply to comment #5)

If we use some codes that will never exist in the external data, wouldn't it
make sense to just hard-code those here?

Then it would no longer be a data-driven flexible approach. That would not
make
sense. We have data that fails now; at some point in time, some missing data
will be added, and when it does, all the better.

You said we have "wikis for languages codes that do not exist (anymore). Those can never be supported." What if we just hard-coded those particular languages? Being data-driven and flexible is a nice ideal, but where it doesn't seem to be possible we could go with the next-best thing, no?

bua, lbe, lmo, & vec are all valid codes, and should be in CLDR, and should flow through from there. I see them here in CLDR

http://unicode.org/cldr/utility/languageid.jsp?a=bua
http://unicode.org/cldr/utility/languageid.jsp?a=lbe
http://unicode.org/cldr/utility/languageid.jsp?a=lmo
http://unicode.org/cldr/utility/languageid.jsp?a=vec

Is there another step needed to add them to the CLDR datasource that mediawiki uses?

be-x-old is also listed in that registry

http://unicode.org/cldr/utility/languageid.jsp?a=be-x-old

roa-tar isnt

http://unicode.org/cldr/utility/languageid.jsp?a=roa-tar

If we need to add a code, we can ask the relevant wiki community to compile the data needed to submit a new code request
http://cldr.unicode.org/index/cldr-spec/minimaldata

Sorry for failing to update this bug, but Lloffiwr and I are working on the problem, which will be solved upstream in few days for English and then for all languages between May-June if we find all translators.
This bug report mixed various matters and we're not going to update it anyway, so I'm closing it.
Please watch the following:

• https://translatewiki.net/wiki/Thread:Support/Language_names_not_in_Unicode_CLDR
• http://unicode.org/cldr/trac/ticket/6763

Whoever is interested in adding language names translations to CLDR is invited to drop me an email. Thanks!

(In reply to John Mark Vandenberg from comment #8)

If we need to add a code, we can ask the relevant wiki community to compile
the data needed to submit a new code request
http://cldr.unicode.org/index/cldr-spec/minimaldata

Actually that's not needed.

emmons (CLDR technical committee chair) said:

There are two different possibilities:

a). You are asking us to add a bunch of new language names into the English source for CLDR, and subsequently either providing translation of those language names (or hoping that others do) into other CLDR locales that we ALREADY HAVE on the books.

or

b). You actually want to create new CLDR locales for all these languages - which is a MUCH bigger undertaking, and not something we have the manpower or resources to pursue at this time.

Sorry, not "in few days" but yesterday! \o/
http://unicode.org/cldr/trac/changeset/10166

If something is not included there it means that it's trickier, so you should file a separate ticket specific to it and similar to http://unicode.org/cldr/trac/ticket/6763 .