list of languages incorrectly localised

[jonorthwash]

Expected behaviour:

• If language name is localised, display that
• Else if language name is natively localised, display native name
• Else display ISO code

Current behaviour:

• If language name is localised, display that
• Else if language name is natively localised and has a two-letter code, display native name
• Else display ISO code

Here's an example: http://turkic.apertium.org:8080/listLanguageNames?locale=arg returns

{"es": "espanyol", "cs": "checo", "eo": "esperanto", "kaa": "karakalpak", "cu": "eslau eclesiastico", "as": "asam\u00e9s", "nl": "neerland\u00e9s", "th": "tailand\u00e9s", "ast": "asturiano", "sma": "sami meridional", "ru": "ruso", "bg": "bulgaro", "udm": "udmurt", "sw": "suahili", "ckb": "kurd sorani", "fi": "fin\u00e9s", "ta": "tamil", "nog": "nogai", "tg": "tadjik", "no": "noruego", "se": "sami septentrional", "mk": "macedonio", "fy": "fris\u00f3n oriental", "ia": "interlingua", "gn": "guaran\u00ed", "gd": "gaelico escoc\u00e9s", "vi": "vietnamita", "ht": "haitiano", "az": "azeri", "zu": "zul\u00fa", "sh": "serbocrovata", "gv": "manx", "it": "italiano", "sq": "alban\u00e9s", "ms": "malayo", "de": "alem\u00e1n", "hu": "hongaro", "ml": "malayalam", "kk": "kazakho", "te": "telugu", "lb": "luxemburgu\u00e9s", "el": "griego", "fa": "persa", "br": "bret\u00f3n", "lg": "ganda", "ur": "urd\u00fa", "smj": "sami lule", "uk": "ucrainiano", "ceb": "cebuano", "is": "island\u00e9s", "tet": "tetun", "oc": "occit\u00e1n", "kum": "kumiko", "ca": "catal\u00e1n", "pa": "panchab\u00ed", "nn": "noruego nynorsk", "tk": "turcomano", "ba": "baixkir", "tl": "tagalog", "uz": "uzbeko", "mr": "marathi", "csb": "caixubio", "dsb": "baixo sorabo", "myv": "mordoviano erza", "tt": "tartre", "bua": "buriat", "hr": "crovata", "bi": "bislama", "lo": "laosiano", "la": "lat\u00edn", "sco": "escoc\u00e8s", "mfe": "mauriciano", "pl": "polon\u00e9s", "ko": "coreano", "sk": "eslovaco", "av": "avaro", "kv": "komi", "an": "aragon\u00e9s", "xh": "xosa", "nb": "noruego bokm\u00e5l", "eu": "basco", "he": "hebreu", "sa": "sanscrito", "gl": "gallego", "ro": "rumano", "mt": "malt\u00e9s", "cv": "chuvaixo", "af": "afrikaans", "lv": "let\u00f3n", "ar": "arabe", "rm": "romanche", "sl": "esloveno", "sr": "serbio", "sc": "sardo", "rup": "arrumano", "zh": "chino", "be": "belorruso", "bn": "bengal\u00ed", "hsb": "alto sorabo", "hi": "hindi", "ga": "irland\u00e9s", "en": "angl\u00e9s", "pt": "portugu\u00e9s", "fr": "franc\u00e9s", "rn": "rundi", "fo": "fero\u00e9s", "et": "estonio", "sv": "sueco", "ne": "nepal\u00e9s", "ku": "kurdo", "hy": "armenio", "sah": "yacuto", "tyv": "tuviniano", "si": "singal\u00e9s", "bs": "bosnio", "cy": "gal\u00e9s", "tr": "turco", "os": "osseto", "ky": "kirgu\u00edz", "lt": "lituano", "da": "dan\u00e9s", "co": "corso", "id": "indonesio"}

The dropdown shows the following, with crh, gag, and ug not localised in arg:

While ug is shown with its native name, crh and gag are not, despite being natively localised, as shown by the output of http://turkic.apertium.org:8080/listLanguageNames?locale=crh and http://turkic.apertium.org:8080/listLanguageNames?locale=gag, respectively:

{"crh": "q\u0131r\u0131mtatarca", "gag": "\u011fa\u011fauz\u00e7a"}

{"gag": "Gagauz\u00e7a"}

[Jeewal]

I'd like to try and work on this one!

[sushain97]

@Jeewal sure! Feel free to send a PR or ask for help.

[sushain97]

Oh, I remember why this problem occurs! Autoglottonyms are hardcoded in localization.js for technical reasons. The output of APy is irrelevant.

[jonorthwash]

o_O

[sushain97]

It's because APy doesn't support a "return autoglottonyms for all languages" call, only "return all glottonyms in X language". To replicate the first with the second would require N calls of the second where N is the number of languages. So, we put them into localizations.js instead (one of the top couple lines).

[jonorthwash]

I see. Is our algorithm for localising the names still "1. check in interface language, 2. check in own language, 3. fall back on code"? And 1 queries APy and 2 checks the local localisations file?

Could we just do all those queries up front at make and build a separate file with that data? I guess we already do a lot of requests at make?

[sushain97]

Yes, exactly correct on all counts.

We could do all the queries but that would be 100+ e.g. on beta.apertium.org. Would take forever for the build indeed.

On Jan 14, 2018 11:13 PM, "Jonathan Washington" notifications@github.com wrote:

I see. Is our algorithm for localising the names still "1. check in interface language, 2. check in own language, 3. fall back on code"? And 1 queries APy and 2 checks the local localisations file?

Could we just do all those queries up front at make and build a separate file with that data? I guess we already do a lot of requests at make?

— You are receiving this because you commented.

Reply to this email directly, view it on GitHub https://github.com/goavki/apertium-html-tools/issues/210#issuecomment-357584670, or mute the thread https://github.com/notifications/unsubscribe-auth/AEBEfqQnSOF32g-vn3dY1Fe-bAEqfFUMks5tKt5sgaJpZM4Qa_AS .

[jonorthwash]

Would take forever for the build indeed.

So can you think of another way to keep everything in one place and perhaps synchronise it elsewhere?

[sushain97]

We could have a function in APy that creates the list then we update it manually in localisation.js. Or, we could add the somewhat specialized endpoint to APy that retrieves autoglottonyms for the specified codes.

On Jan 15, 2018 12:56 PM, "Jonathan Washington" notifications@github.com wrote:

Would take forever for the build indeed.

So can you think of another way to keep everything in one place and perhaps synchronise it elsewhere?

— You are receiving this because you commented.

Reply to this email directly, view it on GitHub https://github.com/goavki/apertium-html-tools/issues/210#issuecomment-357763372, or mute the thread https://github.com/notifications/unsubscribe-auth/AEBEfgpTXmwg-n6ppId0HkmzrS66vLb7ks5tK59BgaJpZM4Qa_AS .

[jonorthwash]

I'm okay with either, though I kind of like the idea of just having an endpoint for it.