Addressing localization requirement

[JMStudiosJoe]

Choose from pre translated dropdown text values of of the local disaster for consistent translations.

[sunnymui]

We will be working on a shared spreadsheet to define what terms/phrases will be available for use in disaster posts and the interface.

These pretranslated terms will be selectable by an admin user for building a disaster post. For the interface of the app itself, a language switcher to switch language of buttons and interface stuff would be good.

We should review past SJ disaster news releases to help us understand what phrases to include.

Feature Rationale

A major priority for the Office of Emergency Management through this initiative is to deliver translated notifications that are accurate and understandable by our audiences.

A major challenge for the City of San José is making language services seamless for residents such that an interpreter or translator is not a barrier for them to engage. This experience is especially difficult to orchestrate during emergency situations. Often, notifications will be sent to bilingual staff for translation. Especially in the context of critical information, making residents feel safe and prepared is a priority.

Priority Languages.

• Vietnamese
• Spanish

According to the original SJ government Request for Proposal doc, their difficulty communicating emergency notifications impacted Viet/Spanish speakers the most:

"Disproportionately impacted by these methods of communication are non-English speaking residents (predominately Vietnamese and Spanish), low-income, and elderly individuals, for whom these emergency notifications are not efficiently conveyed."

According to SJ city data on other languages spoken:

The most common languages spoken by non-English speakers are Spanish (23% of total resident population), Vietnamese (10% of total resident population), Chinese (including Mandarin, Cantonese; 7% of total resident population).

To Do

• Rework the admin interface to allow building a disaster post using these pretranslated phrases.
• Allow language selection by app users
• Handling of storage/retrieval of translated phrase list in app
• Explore what needs to be translated (common disaster terms. numbers? locations?)
• Compile list of terms/phrases to translate
• Get translations of all phrases

Original RFP requirements readable at: https://docs.google.com/document/d/1mPfOb2xVBXfbWRODLt4SqjNzkF31ozSQRZaUpJea5pI/edit?usp=sharing

[sunnymui]

Some good notes on language switcher UX for the UI choices:
https://uxdesign.cc/my-take-on-language-selectors-945caceb58f7

TLDR:

• Use the full name of the language in a switcher
• Show language names as they are written in that language
• Use an icon, either a globe or something similar to the google translate logo
• Have a language switcher in the top nav and in the footer
• Ideally you can show all the language names as links instead of hidden in a dropdown, but this can be unwieldy if you have many languages. You can show most common choices based on user location though.

[sunnymui]

Some points to keep in mind based on mistakes made in Vietnamese translation on the SCC website:

The county public health department’s Vietnamese-language webpages such as https://www.sccgov.org/sites/phd/DiseaseInformation/novel-coronavirus/Pages/info-viet.aspx are difficult to read due to an encoding problem. (They’ve used Unicode NFD instead of NFC, i.e., combining characters instead of precomposed characters, and their font doesn’t handle combining characters well.) I’ve noted this in the in-page feedback form but if anyone has a contact at the department, I’d appreciate if you could pass the word along.

[1ec5]

Some points to keep in mind based on mistakes made in Vietnamese translation on the SCC website

The combining characters on the Public Health Department’s website would be readable, except that the particular font they’re using doesn’t have great kerning for combining characters. Fortunately, the disaster response site probably doesn’t use the same font.

[1ec5]

Before the site can be translated, user-visible strings in the site probably need to be made localizable. I’m not very familiar with localization for React sites, but it looks like various strings are embedded directly in markup:

disaster-response-sj/src/compositions/PostMarkup/PostMarkup.js

Lines 33 to 37 in 4615b20

	name = 'title'
	value = { title }
	type = 'text'
	label = 'Title'
	tooltip = 'Title'

A spreadsheet-based workflow may be appropriate if the site will only have a handful of fixed strings in one or two languages. However, beyond that, it can be time-consuming for project maintainers to synchronize the spreadsheet with the repository and difficult for translators to keep track of the spreadsheet.

Ideally, there would be some way to extract these strings into a single file that translators can translate directly. There are translation management services like Transifex that provide a user-friendly translation UI and a command-line tool that synchronizes the repository. (Transifex is free for open-source projects like this site. It supports a variety of translation file formats, including JSON, YAML, and XLIFF.)