Monthly Ideation meeting: 2022 March 29th

Logistics

2022-03-29T13:00:00Z2022-03-29T13:50:00Z

:tv: Google meet room: https://meet.google.com/nuq-pztb-asu

If you’d like access to the google meet room, send a message to the @maintainers group. If you’d like to be added to the calendar invite please DM @eriol .

:writing_hand: Who will take notes? :raised_hands:
To take notes, all’s you got to do is make a riseup note pad here: https://pad.riseup.net/

Today’s Riseup pad: Riseup Pad

Monthly Ideation meeting: 2022 March 29th

Topic: Possible topics include:

  1. OTF’s Red Team survey and survey logic: OTF Apply | Red Team Lab

  2. How do applicants want to send in applications? Always with the same email? Anonymous? etc. Anyone can associate an application with a user if they know their email · Issue #2760 · HyphaApp/hypha · GitHub

  3. Split an application into multiple pages & conditionally direct a user to specific pages [Meta] Add the ability to split an application into multiple pages & conditionally direct a user to specific pages · Issue #1961 · HyphaApp/hypha · GitHub

  4. What does the files tab need to do for users [Files tab spike]: what does the files tab need to do for users · Issue #2634 · HyphaApp/hypha · GitHub

Github issue/META/EPIC link: IF APPLICABLE

Relevant we.hypha posts links: IF APPLICABLE

Notes

Selected Topic: Localization

  • There are no localizations currently done for Hypha

  • The basic mechanics are in place for localization

  • What has been done?

  • Potential directions: We could get all of the stock language translated in the top 5 languages on the internet

  • Localizing for a particular use case — might not be a common feature, could be something that each adopter is responsible for

  • It’d be nice to have some documentation or instructions for how to do localizations

  • Question: How to support applicants in multiple languages?

  • What do we (or they) mean by localization?

    • e.g. do they mean can people apply in any language vs the application is presented in multiple languages
    • Idea: Users could indicate what language their application is in, and on the backend the program officer could be offered a translation (either via human or technical translation)
    • Can we help support people who speak multiple language and let them see that their translation is acceptable to capture nuance? (e.g. folks who speak Arabic and English, but are more comfortable writing in one language than the other).
    • Idea: Users can set their language on the platform
  • What do we do about compliance support (e.g. contracts, etc)

    • How would translation intersect with contracts, etc
    • Example from SimSec experience: We’ve gone back and forth with funders to get the language correct for the thing of record (e.g. a contract/proposal in German)
    • Would be a question for each funder to consider
    • Do people want to trust Google translate? Or trust people to do those translations?
    • This speaks to a need to setup the implementation so that the adopter could chose their mechanism (e.g. automated translation too, vs person translated, etc)
    • From previous projects: Bernard has implemented tools where they have side by side translation available — Welsh & english side by side, also tried with arabic + english, particularly for folks who actually weren’t fluent in both — provided them with both languages actually provided them with a lot more support
  • First Question: Can the funder offer an application in a language other than English?

  • Second Question: Would the applicant be open to having their application translated into the funders “official” language

  • OTF has experimented with having people apply in other languages depending on the program officer

  • Process-wise where would we go to next steps?

    • Should it come to the summit?
    • GA: Suggestion is that we share these notes & the synthesis, we maybe adjust/adapt/improve any docs that currently exist, and propose this as a topic for further exploration and prioritization at the summit
    • Expand on the Hypha docs translate documentation
    • Where does this belong?
      • Contributors: Contributing Translation
      • Administrators: Technical Documentation re: setup & system language choice
      • FAQs/main page: Overview of the current functionality
      • Also… customization for cultural context (e.g. Dismiss > Decline)
      • Important, but can be built into the overview of what localization means
  • ARDC (@rosy ) has done some work here, also DFF (@vinkthom @allan ) — Worth asking them how they’ve approached it

    • Could be a good narrative here (e.g. blog post, case study, etc)

Next Steps:

  • Share these notes :white_check_mark:
  • Create issues for the lightweight documentation (@emlini )
  • Raise to the @Adopters for priortization at the Summit

Hi Everyone!

This is today, and @bernard and I will help facilitate. We’ll start by picking a topic.

See you there.

-Georgia

Hi @Adopters ! We had a great conversation about localization today. Please review the notes if you are interested. Github issues to come.

Thank you, this does sound like an interesting conversation! At DFF, so far we have only ever accepted applications in English. But we have identified this as a barrier, given our funding can cover work across all Council of Europe countries. So accepting applications in other languages and having them translated is definitely something to consider. We are a small team and wouldn’t have the resources or capacity (or language skills) to translate in-house. Another thing to consider is the data protection and privacy issues related to tools like google translate. One of the reasons why we are using Hypha and running it on our own virtual private server is to try and keep control over user data. Thanks!

A question I have about Hypha’s current functionality is whether the text boxes that Applicants type into have any kind of language restriction on them. Could a person, for instance, type and submit an application in Spanish, or Japanese, without the system returning an error? Are there any restrictions on special characters (e.g. in the Applicant Name field?)

I could test this out, but I thought I’d start by seeing whether anyone (e.g. @frjo) has an answer straight off.

@vinkthom thanks for confirming that some adopters would like to be able to accept applications in other languages. We touched on, but probably didn’t explicitly note, the security (and validity) concerns with machine translation, but that should be an issue that is made more front-and-center in any future discussions.

1 Like

Hypha is Unicode from start to end so no language restrictions.

You can type and display Arabic, Tamil, Chinese and Japanese characters as easily as you type and display the Roman letters used in most European languages.

Typing a RTL language on a LTR page is an annoyance but something I think many are used to endur since so much is in English only.

The interface is translatable since our big push to get that in place.

The problem is the stream forms (application/review/determination). They have no translation capability. You can only create them in one language (but any one language you like).

Language direction support is missing as well. Setting Hypha to RTL is a small fix but to make it look good the theme/CSS would need some work I assume.

past conversations on localization and terminology

I also added localization as a potential Hypha Summit topic here Hypha Summit 2022 - #2 by dluong

I started drafting basic instructions – please feel free to suggest edits. Thanks.

Getting Started on Localization

Translations of Hypha can be of two kinds. Translations in to another language or translations in to you organisations vocabulary, or a combination of both.

We use Weblate to manage translations of this project. Please visit Hypha’s Weblate Hypha @ Hosted Weblate to start the translation process. You can create a Weblate account, and take it from there. Weblate instructions and related documentation on translation is a great introductory resource. project on Weblate to contribute. If you are experiencing issues while you are working on translations, please open an issue on [GitHub}.

Adopters could also consider installing another translation service or apps for Linux/Windows/macOS po-files. In the How to Edit the .po file in hypha/locale we describe how translators can edit directly with a text editor. All translations will eventually be stored as django.po files.

Adding a language

If your language is not listed on packaging.python.org, click the button Start new translation at the bottom of the language list and add the language you want to translate.

Case Study

In an effort to localize how currency appears on applications, one adopter changed the default currency for their instance from USD to EURO. This adopter’s application accepts the euro currency format . (full stop) instead of , (comma) for the thousands separator and the system read this as a decimal point. so a EUR 2.000,00 (integer 2 instead of 2000) budget was recorded.

How to Edit the .po file in hypha/locale

Hypha has translations to common strings propagated across other components within it by default. This lightens the burden of repetitive and multi version translation. The translation propagation can be disabled per Component configuration using Allow translation propagation in case the translations should diverge.

Hypha’s list of translatable strings is available here.

In cases where text strings are not yet translatable, a quick method to find out would be search in the .po file here. As an Adopter you could also edit “hypha/locale/en” and “hypha/locale/[your_lang_code]” any way you like.

@dluong I like the idea of a localization conversation at the Summit, especially the idea of discussing how recent adopters have made changes, and challenges they’ve had!

Relevant github issues for adding this info to documentation, so we have them with this thread:

Per my last conversation with @frjo, I thought there were two ways to make language changes in Hypha:

  1. change the django.po file directly, or
  2. create a new translation in Weblate

Do we want to recommend one over the other?

I appreciate the link to Weblate’s documentation, and we’ll definitely want to include that, but I think we will also likely want to include some basic steps for creating a new “translation” within Hypha’s Weblate, with some pertinent information, e.g.:

  • how creating a new translation affects Hypha’s code repository, if it does
  • suggestions we have on naming conventions for new translations
  • info about whether there is a process for checking/editing translations, etc.)

I know @bernard has played around with Weblate a bit, so he might have things to add to this. I’m also planning to look into it more.

Re: the Case study you included:
This is really interesting and definitely relates to the issue of localization/translation, but I’m not sure whether the current localization/translation infrastructure we have supports making this kind of change. It seems like the kind of change that would be made elsewhere in settings rather than via the django.po file (or via Weblate). @vinkthom, how did DFF handle this issue in their implementation?

Anyway you translate it will end up as django.po files.

Weblate and other similar services gives a nicer GUI for the translator. There are also a number of apps for Linux/Windows/macOS for po-files. Or if you feel up to it you can edit them directly with a text editor.

But the end result is always the same.

1 Like

You mean about changing from USD to EUR and full stop, comma change. We will have to ask @allan about that. When we first implemented Hypha I just asked him to make the change and he did it :grinning:

1 Like