Update Spanish translations

[duncandewhurst]

Related issues

• Update Spanish translations #467

To-do

• Pull translations once complete and reviewed
• Replace curved quotation marks (‘ and ’) with straight quotation marks in translated strings
• Correct erroneous translations of terms in backticks
• Fix the broken references reported in the build errors
• Fix erroneously translated codes (terms in single quotes)
• Push corrected translations to Transifex
• Fix Remaining issues (see Update Spanish translations #497 (comment))
• Pull updated translations from Transifex

[duncandewhurst]

From reviewing the built docs, their remains some untranslated content and a few other issues:

• Diagram
• Top-level .description in the schema
• Business logic in contractingProcessStatus (Evelyn to translate via Transifex)
• Broken link formatting in field descriptions, e.g. language, typically due to the translation adding whitespace between the ] and (. Need to check all field descriptions.
• Broken link formatting in Markdown, e.g. in the second paragraph of packaging data. Need to check all Markdown content.
• Missing schema browser on packaging data (Duncan to investigate)
• Some untranslated content in the changelog
• Diagrams on implementation models (Evelyn to translate the Google drawings)
• Markdown content on publishing data in your own language (Evelyn to translate via Transifex)
• Internationalization lookup table on publishing data in your own language (TBC - see comment below)
• Markdown content on CoST IDS to OC4IDS mapping landing page
• I'm not sure if it makes sense to translate the sub-schema headings, given that the tables rendered by the jsonschema directive reference the sub-schemas by their English names. Likewise for the codelist subheadings/names. (Duncan to update)

[duncandewhurst]

@jpmckinney would it be possible to use OCDS Babel to extract and translate the strings in the internationalization lookup table, whilst reusing the existing translations of the schema titles?

Essentially, only the title, translatable and notes columns need to be translated, and the translations for the title column already exist in the translated schema.

[duncandewhurst]

* [ ]  Missing schema browser on [packaging data](https://standard.open-contracting.org/staging/infrastructure/translations/es/reference/package/#packaging-data) (Duncan to investigate)

The browser is missing on the English version too so the issue is unrelated to the Spanish translation. Based on the following error in the web console, I think it is due to the packaging schema referencing the project schema's canonical URL for version 0.9.5, which won't exist until we publish the 0.9.5 release:

XHRGET
https://standard.open-contracting.org/infrastructure/schema/0__9__5/project-schema.json
[HTTP/2 404  285ms]

I'll add a reminder to check this to #486

[ ] I'm not sure if it makes sense to translate the sub-schema headings, given that the tables rendered by the jsonschema directive reference the sub-schemas by their English names. Likewise for the codelist subheadings/names. (Duncan to update)

On reflection, I think it's better to leave these translated, since implementers don't actually need to reference the sub-schema or codelist names in their implementations, and it's better for the navigation menu to be in Spanish in the Spanish docs.

[duncandewhurst]

@jpmckinney would it be possible to use OCDS Babel to extract and translate the strings in the internationalization lookup table, whilst reusing the existing translations of the schema titles?

Essentially, only the title, translatable and notes columns need to be translated, and the translations for the title column already exist in the translated schema.

Only the titles remain untranslated, so I'm happy for this PR to be merged as-is.

[jpmckinney]

For images, an idea we can explore in future is to export as SVG (which is just HTML text), and then paste that text into the Markdown files, adding whitespace around translatable text so that MyST-Parser extracts it. However, I think this will only work if the translated text is of similar length (otherwise, it might extend beyond the boxes). It might also require being more careful about the size and alignment of text elements in the SVG.

[jpmckinney]

The internationalization lookup table does:

```{csv-table}
:file: ../_static/i18n.csv
:header-rows: 1
```

MyST-Parser should already extract each cell in the CSV as a separate translatable string. Is that not the case?

[duncandewhurst]

For images, an idea we can explore in future is to export as SVG (which is just HTML text), and then paste that text into the Markdown files, adding whitespace around translatable text so that MyST-Parser extracts it. However, I think this will only work if the translated text is of similar length (otherwise, it might extend beyond the boxes). It might also require being more careful about the size and alignment of text elements in the SVG.

Sounds good, and I know that BODS already do that. I created an issue: #507

The internationalization lookup table does:

```{csv-table}
:file: ../_static/i18n.csv
:header-rows: 1

MyST-Parser should already extract each cell in the CSV as a separate translatable string. Is that not the case?

Yep, it does that, but the field paths in the first column shouldn't be translated (I used the bulk editing feature in Transifex to copy the source string to the translation) and the field titles in the second column are already translated in the schema resource, but appear as untranslated in Transifex. The existing translations do appear as '101% match' suggestions in Transifex, but there's no bulk editing option to apply suggestions, so it would be necessary to apply the suggestions one-by-one for the 691 fields in the table. For the time being, I simply copied the source strings to the translation, as with the field paths, which is why they look untranslated in the built docs.

[jpmckinney]

If you don't want a column to be translated, then you need to use csv-table-no-translate and then configure OCDS Babel to discover the CSV. For example, we've done this before with babel_ocds_mapping.cfg (if you search for that, you'll find all the locations where you'd need to configure a new type of CSV).

To bulk translate, you'd need to use pretranslate from translate-toolkit like at https://ocds-standard-development-handbook.readthedocs.io/en/latest/profiles/translation.html or at https://github.com/open-contracting/ocds-extensions-translations/blob/main/README.md

Since you already added translations that you don't intend to keep, I think you would have to:

• Backup the PO file for the page to be translated
• Create a blank PO file for the page to be translated, from its POT file
• Pretranslate the strings from the schema, using the schema's PO file as the compendium
• Pretranslate the remaining strings, using the backup as the compendium

[duncandewhurst]

Great. Thank you! Those instructions are very helpful. I'll tackle the update as an iterative improvement so as not to delay the 0.9.5 release further. I created an issue: #510