Internationalisation: some strings not translated/translatable in schema tables

kd-ods commented 5 years ago

See: http://standard.openownership.org/ru/0.2-dev-ru-translation/schema/reference.html#publicationdetails

The values under the last three columns (Type, Format, Required) are not translated. So we have 'string', 'object', 'date', 'uri', 'Required' etc. Now this might be acceptable, since these are keywords in JSON schema.

However we also have 'See' (as in 'See Publisher') left untranslated. That should be translated.

odscjames commented 5 years ago

I will want to have a quick chat with @rhiaro about the translation process when she has time ...

siwhitehouse commented 5 years ago

There are some more places where we have non-translated strings, notably in some of the headings and navigation menu strings. I've completed the import of the sphinx-theme strings today (many thanks to @odscjames) and I'll detail them on Monday.

siwhitehouse commented 5 years ago

See http://standard.openownership.org/ru/0.2-dev-ru-translation/index.html where the headings "For Newcomers" and "For Developers" have not been translated.

Checking in https://www.transifex.com/OpenDataServices/bods-v02/translate/#ru/about--index/174975439 shows that this did not get pushed up to Transifex (assuming that is the correct file).

Checking locally in the docs/locale/ru/LC_MESSAGES/index.po file I don't see either of these headings.

odscjames commented 5 years ago

I separated the front page issue into https://github.com/openownership/data-standard/issues/223

rhiaro commented 5 years ago

'string', 'object', 'date', 'uri', shouldn't be translated as these are JSON keywords.

In the context of the docs, 'Required` could be. I spent an hour hunting through all of our own templates, as well as the jsonschema and Sphinx source code and I can't find where this "Required" string, or "See" come from though. Most useful clue I found on my treasure hunt is https://github.com/lnoor/sphinx-jsonschema/blob/master/sphinx-jsonschema/wide_format.py#L73 possibly, for "See"? I think it then gets handed to Sphinx templating. To be continued.

rhiaro commented 5 years ago

Update: @odscjames found the offending line, I was looking in completely the wrong place: https://github.com/OpenDataServices/sphinxcontrib-jsonschema/blob/openownership/sphinxcontrib/jsonschema.py#L142

siwhitehouse commented 5 years ago

Am I correct in thinking that we have identified where the issue lies, but not necessarily how to fix it?

rhiaro commented 4 years ago

We could do a slightly hacky BODS-specific fix (1), or add full i18n support to the sphinxcontrib-jsonschema library (2).

1. Replace text with an icon

eg. 'See' becomes ⎘ or similar so there's nothing to translate. Will either need to be:

a) via the externallinks option in the BODS docs to override every place there's an automated 'See' link (probably too much overhead and chance of missing one), or b) in our sphinxcontrib-jsonschema fork

'Required' is translated in the column header, so the word 'Required' which is printed by sphinxcontrib-jsonschema in each cell could be replaced by ✓or * . This would need to be done in sphinxcontrib-jsonschema directly.

2. Add i18n support to sphinxcontrib-jsonschema

This will involve:

adding a dependency in sphinxcontrib-jsonschema for gettext
marking up all strings in sphinxcontrib-jsonschema with _('...') (apart from 'See' and 'Required', other strings are errors, warnings, and validation messages.)
making a transifex project for sphinxcontrib-jsonschema and doing the translation dance
including the sphinxcontrib-jsonschema LOCALE directory in the BODS docs conf.py list of LOCALE directories

We can do this (in order of simplicity):

a) In the openownership branch. b) In master so other standards can share it. (what if different standards need different sets of languages? One tx project per standard and different tx configs on different branches?) c) In master and PR upstream in case it's useful to the rest of the world. (who is in charge of the translations?)

Bonus: externallinks

Neither of the previous options solve translation of labels passed using the externallinks option in the RST files. We could solve this by:

writing a new babel extractor for that particular bit of config in the RST files (seems like overkill)
putting this text somewhere that gets picked up by one of our existing extractors (haven't figured out where yet though... metadata in the schema itself? A whole new JSON file just for such meta?)

Or we could not solve it, but change its usage. Currently externallinks is used 9 times in reference.rst to point to codelists, with the text 'Codelists'. These could potentially all be replaced by the name of the codelist (eg. entityType) in an inline code block, so its clearly showing the json key instead of a translatable string. Once clicked, the codelist name is translated (in brackets, after the key, through the normal translation mechanism).

ScatteredInk commented 4 years ago

I like the sound of the "not solving" solution - but think we can put off a decision on this until we do another translation or release.

timgdavies commented 4 years ago

@siwhitehouse Can you confirm whether this is still an issue or not?

rhiaro commented 2 years ago

Having thought about this more, I think adding i18n support to sphinxcontrib-jsonschema is the right thing to do, and not much more effort than the suggested non-fixes - work in progress. It will need a new transifex project, but there will only be a handful of strings in it.

Re-labelling the "Codelist" externallinks to use the codelist names (and therefore avoid translating) is done.

kathryn-ods commented 4 months ago

@kd-ods do we need to keep this open for awareness while @odscrachel is working on the translations of 0.4? It looks like this hasn't changed in the 0.2 and 0.3 translations

kd-ods commented 3 months ago

Yes. Keep open and we can review post-0.4.

openownership / data-standard