Ukrainian localisation

[mihailik]

🔍 Search Terms

"Ukrainian" "localization"

✅ Viability Checklist

• [x] This wouldn't be a breaking change in existing TypeScript/JavaScript code
• [x] This wouldn't change the runtime behavior of existing JavaScript code
• [x] This could be implemented without emitting different JS based on the types of the expressions
• [x] This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
• [x] This isn't a request to add a new utility type: https://github.com/microsoft/TypeScript/wiki/No-New-Utility-Types
• [x] This feature would agree with the rest of our Design Goals: https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals

⭐ Suggestion

To everyone's shame there is no Ukrainian localization of TypeScript.

I am willing to contribute the bulk of work, and adhere to any specific standard and practice to make it happen. Hope to help Microsoft not to spend much effort, and gain the good will.

If your internal tooling has some funky format that's OK, just give me a template for English or even say Spanish and I'll get Ukrainian back to you.

We can also arrange for a linguist professional to look over any concerns, questions and such.

📃 Motivating Example

There is a large body and community of Ukrainian software developers using TypeScript every day.

You'll gain tons of goodwill, and a positive branding from this.

💻 Use Cases

1. What do you want to use this for? -- Reduce friction of mental translation for the newcomers to TypeScript.
2. What shortcomings exist with current approaches? -- great approaches, just no Ukrainian locale.
3. What workarounds are you using in the meantime? -- English locale.

[mihailik]

A context for the new folks: TypeScript doesn't normally take PRs with localisations.

For example, there was a bug https://github.com/microsoft/TypeScript/issues/54079 reported in the Japanese text, and even a PR https://github.com/microsoft/TypeScript/pull/54128 raised.

Unfortunately, it's against Microsoft's process.

What I'm asking is to expand this process just a little, enough for us to help Microsoft to gain a whole extra language locale free of charge on a good will basis. Hope it's not a whole lot of headache to the internal processes.

Thanks a lot dear Microsoft! ❤️

[RyanCavanaugh]

Unfortunately, new languages are more a matter of ongoing maintenance/compliance than an issue of doing the localization itself.

To ship a new language in-box, there's a bunch of work that isn't really "volunteerable". To list a few examples:

• Some country-specific regulations only activate when using that country's language. For example, multiple countries enforce certain special footers on the website because there's a localization for that country's primary language. New regulations can appear at any time, and we need the appropriate compliance department to find out about them, and staffed engineers to comply with them
• Every language needs a maintained list of terminology that is not allowed to be used. Norms shift over time and we need each language to have a current list of terms which need to be rephrased to avoid potential offense or confusion
• We need to be able to localize strings on our release cadence. Volunteers today is great for localizing today, but we may need a string localized tomorrow in a very short turnaround with no advance notice

I'll pass on Ukranian support as a request to our loc team, but we're not able to pick which languages we localize.

[mihailik]

Unfortunately, that means you're currently spending non-trivial resources funding the russian language.

And as the russia is no longer a money-making region, some would say you're subsidising the russian localisation by keeping it afloat.

Shifting these resources from sanctioned loss-making region to Ukrainian language (or any other underserved locale in line for that matter) may be a great way to repair any reputational damage already caused.