Page MenuHomePhabricator

Add image usertesting prototype: Add es/en dictionary to the prototype to enable faster updating of UI strings
Closed, ResolvedPublic

Description

Task
[High priority] Add es/en dictionary to the prototype to enable faster updating of UI strings
@mewoph already started work on this in creating two message dictionaries for en and es in this PR https://github.com/reetssydney/prototypes/pull/5

Applies to
Concept A and B

Where?
Overall

Event Timeline

RHo triaged this task as High priority.Aug 16 2021, 8:15 PM
RHo moved this task from Incoming to Ready for Development on the Growth-Team (Current Sprint) board.
RHo updated the task description. (Show Details)
RHo added a subscriber: mewoph.

Hi @RHo — I wanted to follow up on the implementation for this. The solution I was thinking about before (using data-attribute to specific the message key and replacing them via JS later) wouldn't work well since the HTML would be shown before the real text is added so the user could see the content before the text comes in.

In our engineering discussion today, we talked about having a build step (locally to start with) to generate the HTML w/the right locales slotted in. There will be some scripts that would generate static HTML with the translated messages.

The biggest implication is that instead of making template changes in HTML files, you'd have to make changes in EJS files and run a script to generate the HTML. Would this work for you?

I understand this may be tedious and is certainly not ideal, but it would work for the short term and is more maintainable then maintaining multiple copies of the same files. (In the longer term, as I've mentioned before, if we envision more prototypes like these, we should invest in setting this up properly.)

Hi @RHo — I wanted to follow up on the implementation for this. The solution I was thinking about before (using data-attribute to specific the message key and replacing them via JS later) wouldn't work well since the HTML would be shown before the real text is added so the user could see the content before the text comes in.

In our engineering discussion today, we talked about having a build step (locally to start with) to generate the HTML w/the right locales slotted in. There will be some scripts that would generate static HTML with the translated messages. The biggest implication is that instead of making template changes in HTML files, you'd have to make changes in EJS files and run a script to generate the HTML. I understand this may be tedious and is certainly not ideal, but it would work for the short term and is more maintainable then maintaining multiple copies of the same files. In the longer term, as I've mentioned before, if we envision more prototypes like these, we should invest in setting this up properly.

Hi @mewoph – thanks for the explanation. Given my unfamiliarity with using EJS files and tight timeline to get the Spanish version created where I would be doing the es language updates, I would prefer then to go with the original plan for me to update the UI text in the relevant html files to es once the en prototype is complete. Would it be OK to decline this task for this version? Though I agree it makes sense to come up a more proper set up in future.

@RHo apologies, I should have included an example. It should be fairly straightforward from the template itself. The whole file would have the same structure and content. The only place where this would change would be where the localized strings are.

For example:

<h1 class="header-suggestions">Suggestions mode</h1>

would become

<h1 class="header-suggestions"><%= suggestions-mode %></h1>

And we would have two JSON files like so:

{
  "suggestions-mode": "Suggestions mode"
}
{
  "suggestions-mode": "Suggestions mode (in Spanish)"
}

If that doesn't work, can we hold off of making a copy until the very end? What I really want to avoid is having to make the same changes in two files (potentially four w/the two concepts).

@RHo apologies, I should have included an example. It should be fairly straightforward from the template itself. The whole file would have the same structure and content. The only place where this would change would be where the localized strings are.

For example:

<h1 class="header-suggestions">Suggestions mode</h1>

would become

<h1 class="header-suggestions"><%= suggestions-mode %></h1>

And we would have two JSON files like so:

{
  "suggestions-mode": "Suggestions mode"
}
{
  "suggestions-mode": "Suggestions mode (in Spanish)"
}

If that doesn't work, can we hold off of making a copy until the very end? What I really want to avoid is having to make the same changes in two files (potentially four w/the two concepts).

Ah thanks that is less daunting! Perhaps the order could be firstly to finish the remaining couple of concept B items, then adding in the localised strings?
That way the cloned concept A will have mostly the strings in place?

That makes sense so active development work won't have to be hindered much by having to re-generate the files every time a change is made.

I just thought of another way that could mitigate the additional build step. We could just keep working on the HTML files as they are right now and I'll go ahead and add in the templates (and make sure build scripts & JSON files are ready to go). The page would just look weird like this:

Screen Shot 2021-08-16 at 4.20.25 PM.png (392×1 px, 56 KB)

After we're done, we can just generate the actual files w/localized strings. Would this work for you (the only impact is that real strings won't show up right away)? With this, we can both keep working w/raw files.

That makes sense so active development work won't have to be hindered much by having to re-generate the files every time a change is made.

I just thought of another way that could mitigate the additional build step. We could just keep working on the HTML files as they are right now and I'll go ahead and add in the templates (and make sure build scripts & JSON files are ready to go). The page would just look weird like this:

Screen Shot 2021-08-16 at 4.20.25 PM.png (392×1 px, 56 KB)

After we're done, we can just generate the actual files w/localized strings. Would this work for you (the only impact is that real strings won't show up right away)? With this, we can both keep working w/raw files.

Sure that works for me, thanks!

PR for replacing hard coded strings w/templates - https://github.com/reetssydney/prototypes/pull/15
Still need to update strings that are added via JS

https://github.com/reetssydney/prototypes/pull/15 now has updates to localize strings added via JS.

@RHo These dictionaries have been created public/i18n/en.json and public/i18n/es.json. After this PR is merged, changes should only be made in the base directories (ConceptA, ConceptB). Changes made directory to _en/_es directories will be overridden when localized builds are generated.

Back to In Progress, need to update the article data as well

Here are the files where localized content should be added to:

For UI text:

  • public/i18n/en.json
  • public/i18n/es.json

For article data:

  • public/i18n/en-articles.js
  • public/i18n/es-articles.js