Open Cymrodor opened 1 week ago
I gave it a try and confirmed that the Internationalization Framework used by Bluesky supports cy-GB. As far as I know, no one is currently working on Welsh localization, so this could be a great starting point.
Apologies if this is a small or unnecessary question coming from a non-native speaker, but is it possible to directly use cy instead of cy-GB?
Thanks. As it's OK technically, there's no reason why we can't just use cy.
A Welsh localisation would certainly be great to have! Like @auroursa, I'm not aware that anyone is currently working on it.
Thanks. As it's OK technically, there's no reason why we can't just use cy.
In my opinion using cy
would be preferable, as my understanding is that the country code is usually only added to the name of a locale to distinguish between different national varieties of a language.
Apologies if you're already aware of this, but I have one quick tip: there's no need to translate any of the strings where the line starts with #~
. These are obsolete strings, they no longer appear in the app but they haven't been removed from the message catalog yet.
Great. I understand Bluesky uses Lingui "to manage translations". I'm not familiar with Lingui, but it's apparently the same company as Crowdin, which I am familiar with. Does translation take place on one of those platforms or do we just work on the messages.po file here from Github?
Translators have asked several times if localisation could be managed using a platform like Crowdin:
Crowdin's CEO even left a comment saying that they'd be happy to offer support to Bluesky in setting up on the platform. Unfortunately, the devs haven't taken up that offer yet.
In the meantime, some translation teams have taken the initiative and have set up their own projects on Crowdin. There may be others but the ones I'm aware of are Indonesian, Ukrainian and Chinese & Cantonese.
Sorry for the long answer, the short answer is that you can choose whichever way works best for you and other Welsh-speaking collaborators: either setting up a project on Crowdin or you can simply open a PR and then respond to review comments here on GitHub. This is what I do when I'm updating the French localisation.
If you do work directly from the messages.po file from GitHub, you might want to wait until the 1.94 release is cut and the file is updated, as there have been a huge number of string changes since 1.93.
I looked around earlier and as someone else has already said, we are translators when we localise and we don't necessarily have the same coding/tech/developer skills shared by much of the Github community, so those localisation platforms exist for many good reasons.
Thanks for the tip to wait until 1.94. That suits me. Any idea when?
I looked around earlier and as someone else has already said, we are translators when we localise and we don't necessarily have the same coding/tech/developer skills shared by much of the Github community, so those localisation platforms exist for many good reasons.
Very good point 💯
Thanks for the tip to wait until 1.94. That suits me. Any idea when?
One of the devs said "soon", it might be as early as tonight or it could be a little while longer. I would certainly think sometime next week at the latest, but then I've been wrong before 😅
There’s another way to get the latest translation files, but it requires some programming knowledge.
As I mentioned in #6244, you can refer to the recently merged Thai localization (#5879) to add the necessary extra files manually. Once that’s done, set up a local build environment and run intl:extract --locale cy --clean
to generate the latest Welsh messages.po file. The --clean
flag will automatically discard obsolete translation strings, leaving only the ones that need to be translated.
After that, you can import the file into your preferred localization platform, like Crowdin, use another translation tool, or even just a text editor—whichever works best for you.
In my opinion using
cy
would be preferable, as my understanding is that the country code is usually only added to the name of a locale to distinguish between different national varieties of a language.
Similarly here, I found that browsers and devices tend to support cy
better than cy-GB
. The latter might encounter issues like font fallback, although this doesn’t significantly affect Welsh since the default font can fully display it even with a fallback. Still, maintaining compatibility is always a good practice from a technical perspective.
Similarly here, I found that browsers and devices tend to support
cy
better thancy-GB
. The latter might encounter issues like font fallback, although this doesn’t significantly affect Welsh since the default font can fully display it even with a fallback. Still, maintaining compatibility is always a good practice from a technical perspective.
That's good to know, and useful info from your testing, thanks @auroursa :)
As I wait for 1.94 then, it would be useful to have a clearer idea of exactly what needs to be done. How much or what percentage of messages.po needs to have been translated before that localisation is adopted and available to app users?
I really hope it's not 100%. It shouldn't be.
As I wait for 1.94 then, it would be useful to have a clearer idea of exactly what needs to be done. How much or what percentage of messages.po needs to have been translated before that localisation is adopted and available to app users?
I really hope it's not 100%. It shouldn't be.
I'm not aware of any specific threshold of completeness that the devs have given for accepting a localisation PR, it's entirely up to their discretion.
So this is purely my personal opinion as a fellow translator, but I would think if all the main UI elements and messages, accessibility labels, etc are translated then that might be sufficient? For instance, maybe some of the error messages are a bit less important to have translated immediately when a localisation is made available, and could wait for future updates?
Great to know. That's exactly how I normally prioritise the work. It might not be practical in some languages, but as pretty much every Welsh speaker also understands English, focusing on getting the main UI out in Welsh first is the most efficient and sensible way.
Also, it'll raise awareness and hopefully some users will volunteer to help and share the work.
One thing I don't think I mentioned that the devs do definitely require to merge a localisation PR is to have it reviewed by at least one other native speaker.
They seem fairly flexible on how that requirement is met though, so I don't think the person necessarily has to have a GitHub account. It could be a fellow Welsh speaker on Bluesky, for instance :)
That's yet more information that is really good to know in advance. Now I know, there are some people I can ask.
I imagine all this info would be useful to other language translators as well. Apologies if I've missed one somewhere, but it might be good to have an informative guide to localising Bluesky somewhere.
I imagine all this info would be useful to other language translators as well. Apologies if I've missed one somewhere, but it might be good to have an informative guide to localising Bluesky somewhere.
Yes that is a good suggestion, I (and others like @auroursa) have been giving ad-hoc tips and advice but maybe it would be sensible to try and draft a guide 🤔
The 1.94 release has now been cut (#6430) so the updated English message catalog is now available here:
https://github.com/bluesky-social/social-app/blob/main/src/locale/locales/en/messages.po
Describe the Feature
It would be great to have Bluesky available in Welsh. I can do (most of) the translation work, but am posting this first and will wait a bit in case someone's already started on it somewhere.
Attachments
No response
Describe Alternatives
No response
Additional Context
No response