In the adopters meeting Sep. 22nd (meeting notes here), we discussed the work @frjo and others have been doing to make Hypha text (which I believe the Dev folks call “strings” ) translatable. There are two aspects to this translation:
Translation between different languages that might be used by Applicants.
Translation between different organizations to allow orgs. to use their own terminology
According to @frjo, all strings in Hypha (or many many of them) are now translatable–list of strings can be found here, I believe.
Questions I have/things to discuss:
There should be documentation for how to edit strings, right? Who should do this documentation?
I know we talked about using Weblate for translation–there are links in the meeting notes to relevant weblate pages – is this only for translation between Languages (like English to Spanish)?
If the answer to (2) is “Yes,” what is the process for translating strings between organizations (I have a vague memory of @frjo telling me that one would edit the django.po file that has the list of strings (linked above)
Are there strings that are NOT yet translatable (i.e., not on that list) that we’d like to be?
For instance, @emlini and @rosy find the the “Apply admin” label on the button in the upper right corner of the Hypha Staff Dashboard confusing (link requires login to access, also see photo below)–we’d like to have this button label added to the list of translatable strings if it’s not already on there.
I think that’s it, but please add to the thread (@bernard, @eriol, @vinkthom, @blah) if there are other questions related to this topic that we should address.
If someone wants to translate Hypha into, say Irish, they will do it by interacting with Weblate’s translation website - Hypha @ Hosted Weblate.
I think we can rely heavily, in the beginning, on Weblate’s “how to do translation” documentation. using Weblate means people don’t have to start doing pull requests, etc (unless they want to!).
If e.g. DDP wants to translate Hypha terminology to theirs, they would I think also use Weblates translation website - but they would obviously focus on changing terminology as opposed to changing the language. @frjo What do you think?
You can create an account, and take it from there.
It may be helpful to contact localisation communities like Localization Lab (who work a lot with OTF funded projects on localisation and translation) to do for example starter courses/upskilling in how to do localisation.
I want to say - @frjo correct me as needed - someone interested in translating strings for say DDP would do it with Weblate.
As Fredrik said yes there most probably are text strings not yet translatable. A quick way would be search in the .po file for “Apply admin” if it’s there chances are that’s it. If not, then that needs to be made translateable.
The best way to see what’s actually translatable is to do a translation.
By way of humourous example - in the past I worked on a UK government project for the Passport Office. It needed to be translated to Welsh. We set-up the translation strings. I didn’t speak Welsh, so I translated the site into Pirate Speak:
Yes, I think that would be the easiest. You are of course free to copy “hypha/locale/en” to “hypha/locale/[your_lang_code]” and edit it any way you like. There are plenty of apps to edit po-files. It’s a text file so any editor will work, but not the best experience I think.
@bernard love that there is a “Pirate speak” option. “hornswaggled letters” – a problem I often deal with.
I like that Weblate is the go-to for any translation - I’ve been looking through the Weblate documentation and it’s very nice! They’ve got a Glossary page that I’ll be exploring more, because it’s making me think we might want to populate the “Glossary” component of our current Hypha Weblate page (right now it’s empty).
My impression from a brief read-over of Weblate’s glossary page is that the “Strings” component in a particular language, which is what is currently populated with all (or most of) the translatable strings in Hypha and called the Hypha core component, is for translating into different languages, and the “glossary” page is helpful for translating terminology and supporting cross-language consistency of translations. I’ll keep looking into that to see if that is accurate. I might even try making a Pirate Speak translation of Hypha
Even with Weblate’s very nice documentation, I do still think we will want a page in both the Deployer and the User sections of Hypha’s documentation in which we discuss translations (either of language or org-specific terminology)–reasons for this are to make folks aware that this is an option, and to let them know how to get more information about how to do it. As you suggested, @bernard, I think we should direct folks Weblate instructions for translating and related documentation for the bulk of the “how-to” piece of this.
What I envision being part of Hypha’s documentation on this topic is the following:
The Deployer doc page on Translation can describe the two options for how a deployer might achieve translation–these are:
Editing the .po file in hypha/locale – and we include brief tips on what software to use (like the one @eriol linked in their reply) instructional resources, and possibly warnings about difficulties they might encounter (like the one @frjo mentioned)
Using Weblate - here I think we’d want to outline the general workflow/steps for this process and link either via
select either “Hypha core” or “Glossary” (depending on what kind )
-then “start new translation”) and link the relevant Weblate pages
For the User documentation page, I think we just need something (maybe on the “Glossary” page I’m going to create) that says, “Hey if you want to change these terms to ones that make sense for your organization, you can,” and a link to the deployer documentation.
What the best way to translate for an organization is something I’m trying to figure out right now.
I’ve made en_ARDC as a locale in our fork, which works and is better than what we’ve been doing, which is to maintain modifications to the main English django.po file, but it feels a little bit like a misuse of the locale codes and I wonder what happens if we wanted to have a distinction between en_GB and en_US, say (I noticed “programme” on some slides at the adopters meeting the other day).
According to the Django docs, looks like I could also do those overrides in a Django app, (e.g. hypha.ardc) which would give us some flexibility on the order they’re applied (after en_XX) and keeps a 1-to-1 match to locale names (so, the ARDC locales would just be named “en” and “es” etc.), but I haven’t investigated how to integrate that with Weblate or settled on exactly where to put it.
Unless I was mistaken, there appeared to be some interest from ARDC in non-English languages at the meeting, so I assume we’re going to want to make their custom vocabulary translatable into other languages.
I’m posting here because I’m interested in how others will solve the same issue.
I think your two examples in the lower part of your post are a great start for translation docs. Perhaps adopters can then be invited to make edits, or do their own ‘walkthroughs’ of their recommended dev route for translations once they’ve gotten to a place they’re happy with and ready to write it up? Inviting those contributions in the gitbook docs page is generally a good idea
Based on a brief discussion in the Maintainer’s call 9/28/21 (notes here), it seems that the best way to translate terminology specific for an organization is going to be using Weblate, specifically the “Glossary” component.
The reason for this—as I understand it, @frjo please correct me if I have it wrong—is that the .po file contains every string (aka bit of text, for anyone reading this who isn’t a developer/coder) in Hypha that could be translated, including the strings that might be translated into other languages. If you created a version that has en_ARDC for your implementation, and someone wanted to view ARDC’s Hypha page translated into Spanish, for instance, localization software that does the translations wouldn’t recognize “en_ARDC” as a valid language code and so translation would fail (or it might default to using the .po file in the en_US folder, which wouldn’t include your org-specific terminology).
The primary hurdle to using Weblate to translate that I can see right now is that the Glossary component on Weblate is not populated with the terminology that could be translated between organizations, but it is something we can work on.
@frjo, do you know if anyone can contribute to the Hypha Weblate Glossary (and if yes, what the workflow is for contributions) or if you need specific permissions to contribute? I can also look into this, but thought I’d ask whether the knowledge already existed within our team.
If it turns out you can contribute directly to Weblate, you could potentially start populating the Glossary component with the strings ARDC needs to be org-specific. This is the link to Weblate’s documentation page about Glossaries, and from there you can also get to pages about how to set up an account and add strings and stuff.
If someone with permissions needs to do it, we could create a list elsewhere (e.g. a Google doc) of the org-specific terminology that will need to be translated, and it can be added to the Glossary by someone who can do that.
@bernard Have contact with people at the Localisation Lab, they will know how all this work. They helped us set it all up.
The end product will in all cases, no matter what tools etc. you use, be a django.po file. It just a question of how you most easily create it with the translations you need.
Thanks! I agree en_ARDC is not the right approach and using Weblate probably is. I’m confused about how to use the glossary to do that, though, and I’ve read the docs for that. Seems like it’s about creating shared strings across several apps (“components”)? I suppose one approach would be to create an ARDC component in Weblate, which might line up with having a separate Django “app” for it. I wonder if it’s possible to have one Weblate org cover multiple repos, or would we want to make our own. But I might follow @frjo’s advice literally and store it in en_US for now.
I’ll have another look at the Weblate documentation myself and see if I can figure out how to do it, but of course you go ahead and do what makes sense for ARDC (and I’d love any updates on your process, so we can see what works better and what works less well).
) translatable. There are two aspects to this translation:
– a problem I often deal with.
