Approach to reviewing English text in the IATI Publisher user interface

[emmajclegg]

Off the back of a few issues mentioning user interface text (e.g. #1417), I wanted to invite feedback here on what the easiest way is to review English text in use across IATI Publisher. This would apply to anything end-user facing - i.e. the ODSC team checking and possibly updating the text for titles, buttons, hover over guidance, error and warning messages, etc.

This feeds into a few streams of work planned for this year:

• standardising the use of IATI terminology across different IATI tools (i.e. creating an IATI glossary!)
• making sure user messages are intuitive and written in plain, simple English
• preparing for restarting IATI Publisher translation work into French and Spanish

All of these aim to improve user experience, reduce confusion when switching between different IATI tools and improve accessibility to non-English native speakers.

Ideas on the best way to approach this are welcome - would ODSC working directly on the IATI Publisher code, collaborating via GitHub pull requests be one option? Or can IATI Publisher user interface content be extracted in another format that's easy to review?

[emmajclegg]

(for awareness @robredpath @praweshsth @sarinasindurakar)

[praweshsth]

We already have a list of spreadsheet with the English text that includes all the static pages and error messages, help text etc that we were trying to use them for translation. But the translation was halted and after that there has been changes in the system. We will have to update those spreadsheets. But it will take time to find those changes and update them.

[robredpath]

During 2024 we hope to put in place a new translation process for all IATI tools, which will make the process of managing translations across the technical estate far easier, more consistent, and of better quality. The glossary is part of that, of course.

Our approach is to start with automated string extraction: this starts with marking up the templates with appropriate tags (see this example from OCDS CoVE ), which we can then automatically extract into a .po file, which we can load into a translation tool such as Transifex, and thereafter manage the translations.

You can read more about OCDS's approach in the OCDS Standard Development Handbook - although we won't necessarily follow the exact same process in IATI as we did in OCDS, the basic principles will be similar: mark up templates -> string extraction from tool -> translation tool -> import back to tool

Tools such as Transifex provide functionality to manage translation content, such as being able to "spot the difference" between a new string extraction and the previous one, prompts when a term is defined in a glossary, and so on.

Our experience is that the process of marking up the templates and extracting the strings also presents an opportunity for review of the source language content.

As we get this work underway we will of course discuss this with YI to make sure that what we're creating is possible to implement and easy to work with, and we recognise that converting IATI Publisher to use the new system will be a significant project. Assuming that our budget is as we hope, we will be asking for estimates in due course.

....all of that is to say to @emmajclegg 's question that I think that for now, it's fine to take quite an inefficient approach to things that we spot: maybe prepare a list with screenshots and links and so on of things that we've noticed. Then, as the translation work gets underway, we can take a more systematic approach.

[emmajclegg]

@praweshsth - after discussing within our team today, we think the best approach for a full-scale review of English text in IATI Publisher is best left until we can work with you on automated text extraction (the approach @robredpath describes above). This will take a few months for us to prepare both time and budget-wise, so is something we'll look to do later this year.

In the meantime, I'll raise individual GitHub issues if I think it's worth changing specific parts of Publisher's user interface content before then - likely, only if we see users are getting confused by it.

It's not worth your team updating the spreadsheets you mention that were put together ahead of last year's translation work. I think I've found a file with a lot of the content here from the Publisher handover documentation.

One question on the other IATI tools point - were IATI Validator feedback messages rewritten for use in IATI Publisher, or are the warning and error messages the same as what a user would see on the Validator website?

[praweshsth]

One question on the other IATI tools point - were IATI Validator feedback messages rewritten for use in IATI Publisher, or are the warning and error messages the same as what a user would see on the Validator website?

The error message in IATI Publisher after validation process is same as provided by Validator but without mentioning the column no.