Hey Ruby/Rails world, is there a fantastic VS Code extension that allows me to cmd+click on a t(‘…’) string and jump to the value for that localisation?
i18n
I guess another reason to *not* build your own emoji picker: i18n.
- https://github.com/joeattardi/picmo/issues/75
- https://github.com/missive/emoji-mart/issues/830
Also, this repo is quite interesting: cldr-json https://github.com/unicode-org/cldr-json - JSON distribution of CLDR locale data for internationalization. Seems to have annotations for every character? e.g. `en` https://github.com/unicode-org/cldr-json/blob/main/cldr-json/cldr-annotations-full/annotations/en/annotations.json
Sneak peek on what's coming up for #PhanpySocialDev
Help us test internationalization for Fedora 42! Testing is running from Mar 4-10.
➡️ https://fedoramagazine.org/contribute-at-the-fedora-linux-42-i18n-test-week/
« Econception logicielle, pourquoi et comment coder "green" »
#ecodesign #ecoconception #opensource #a11y #i18n #androiddev #iosdev #webdev #VieDeDev
Support sous CC-BY-SA
the more i see software developers make localization mistakes (such as using the same string for "post" (verb, on a button to make a post) and "post" (noun, on a header when viewing a post), the more i continue to insist that they learn at least a bit of #esperanto
you can learn enough of it in two or three months to be able to read a wide variety of texts, and its grammar is clear enough that it avoids ambiguities that cause localization problems for monolingual english speakers
even if you never speak a word of esperanto again, just thinking about "oh, this is a button to make a post, so i'd use the verb form 'afiŝi' there, and that is a header displayed when viewing a specific post, so the noun form 'afiŝo' makes more sense there" when writing the localization strings will make it much easier for people who want to localize your app or website for french, german, russian, etc. (and probably also other languages, but i don't have enough expertise in that)
I've been wrestling with implementing #multilingual content support in Hackers' Pub, our #ActivityPub-powered platform for software engineers.
While ActivityPub theoretically supports multilingual content through the contentMap property, the reality is that most server implementations (Mastodon, Misskey, etc.) don't properly handle this content as of April 2025. This creates a significant challenge for us.
We want our users to share their knowledge in multiple languages, but we need to ensure compatibility with existing ActivityPub servers. I'm considering several approaches:
Creating separate posts for each language with clear language indicators, linking them through inReplyTo relationships (so translations appear as replies to the original post)
Using the primary language in content while storing translations in contentMap
Adding "View in other languages" links at the bottom of each post
Implementing inline language dividers that degrade gracefully on non-supporting servers, for example:
<div lang="en"> <h3>English</h3> <p>This is the English content…</p></div><hr><div lang="ko"> <h3>한국어</h3> <p>한국어 내용입니다…</p></div>
I'm leaning toward a hybrid approach—showing content in the user's preferred language when possible while providing easy access to other language versions.
Has anyone tackled this problem effectively? I'd love to hear about your experiences or ideas for making multilingual content work well in the fediverse, especially when dealing with server implementations that don't fully support ActivityPub's multilingual features.
Quite annoyed that i18next has many versions of its own JSON format (now v4) https://www.i18next.com/misc/json-format — every time there's a new version, devs have to convert existing translation files to the new format *and* ensure that their translation management platform (e.g. Crowdin) already supports it (and older versions).
Glad that I use Lingui for Phanpy which uses the widely-adopted ICU MessageFormat (https://lingui.dev/guides/message-format)
Note: my other projects use i18next, thus the rant.
#WebDev #i18n