Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Internationalisation of clinician/lay comments #26

Open
eatyourpeas opened this issue Jun 13, 2020 · 8 comments
Open

Internationalisation of clinician/lay comments #26

eatyourpeas opened this issue Jun 13, 2020 · 8 comments
Assignees
Labels
design-decision An issue that documents a past, present or future design decision in the project feature-request New feature or request nice-to-have A feature which would be nice to have but is not essential not-for-mvp Not required for MVP launch

Comments

@eatyourpeas
Copy link
Member

Implement internationalisation and localisation of advice strings to be available in different languages. Any subsequent change in the text, or added support for new languages would then changes in only one place.

@eatyourpeas eatyourpeas self-assigned this Jun 13, 2020
@eatyourpeas eatyourpeas added design-decision An issue that documents a past, present or future design decision in the project feature-request New feature or request nice-to-have A feature which would be nice to have but is not essential not-for-mvp Not required for MVP launch labels Jun 13, 2020
@eatyourpeas
Copy link
Member Author

eatyourpeas commented Jun 13, 2020

@pacharanero Android uses xml string resources to do this and feels to me a good way to go; and the python library can parse xml strings. What do you think? It feels to me preferable to hard code properly translated strings (where we control the tone and quality of translation so important in clinical advice) rather than rely on libraries like python's gettext to do this automatically. If so, is there some better way to parse strings based on locale (eg as a python module) or should we put together an xml file of string resources which we can send back as an api response either in one go, or only in those languages requested in the api request? Or maybe both?
We need to bear in mind #23 (@statist7) where users in future may wish to request their own centile set to return with the calculated values - the advice strings would need to harmonise with that.
Here is a thought experiment.

@pacharanero
Copy link
Member

I agree with using an abstraction for storing the strings. BUT I'd rather we didn't use XML. The same thing can be achieved using YAML (or JSON) with much greater human readability. The way it would work is exactly the same as it would with XML, but just without (bleurgh!) having to handle XML.

@eatyourpeas
Copy link
Member Author

I have created a .yaml file here ready to go. Still needs populating with the English and translated strings and hooking into the growth_interpretations.py functions. I will therefore leave this open for the time being.

@statist7
Copy link
Contributor

You need to check your equivalent sds values. They should extend from -2.67 for the 0.4th centile to 2.67 for the 99.6th, and values close to zero correspond to centiles near the median.

So for example the sds for the 3rd centile is -1.881.

@pacharanero
Copy link
Member

This issue is no longer so urgent, since the Project Board have decided that the lay and clinician comments are to be removed, except for very generic advice regarding interpretation of the results (eg trends rather than point interpretation).

@eatyourpeas
Copy link
Member Author

In fact, now the project board have revised their decision and do want some comments to be returned with the centile value. This is now implemented and so at some point translation will be necessary. Leaving open for the moment...

@pacharanero
Copy link
Member

We can store the strings in Internationalisation/Locale files in YAML and get them using this
https://pypi.org/project/python-i18n/

@pacharanero
Copy link
Member

I will do this in the next sprint.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
design-decision An issue that documents a past, present or future design decision in the project feature-request New feature or request nice-to-have A feature which would be nice to have but is not essential not-for-mvp Not required for MVP launch
Projects
None yet
Development

No branches or pull requests

3 participants