Ethereum-org-website: Break out translation json files

[samajammin]

Is your feature request related to a problem? Please describe.

Our app uses gatsby-plugin-intl for internationalization. This plugin expects a single json file (located at /src/intl/${lang}.json) containing all strings for each language translation.

Here's our current en.json file (~1500 lines):
https://github.com/ethereum/ethereum-org-website/blob/dev/src/intl/en.json

This creates issues with our translation process in Crowdin, where volunteers translate these files. Currently we wait until a file is 100% translated before passing it on to our professional translation review service. Waiting for the entire file to be translated is far from ideal... we want to be able to review & publish translation updates on a page-by-page or even component-by component-basis in order to publish translations ASAP.

Describe the solution you'd like

• Split out the monster en.json file into a set of distinct files (per page? per component? plus common strings?)
• Create a node script to merge these individual json files on build, so the app continues to work with the intl plugin

Describe alternatives you've considered
Still not sure how to best organize the json files...

• Break out the json files by end-user page?
• Break out the json files by component?
• Should we consolidate duplicate strings when possible (e.g. in a common.json)?

[wackerow]

I've been thinking about something like this as I've been working with the translation set up.

As I've been setting them up, I try to organize them by the js file referencing them, which is typically either a page layout , or a reusable component... I think breaking them out by component/page is most natural, that way a new component can have its own language json, and can be translated and approved individually.

I really like the idea of a "common" json as well. I'm not sure how it would work behind the scenes in terms of approving each change however, given that this list would likely change/grow over time as more phrases collide.

@samajammin Side question regarding translations while we're on it: Should we be proactively preparing for syntax issues between languages? Many of our sentences are broken into pieces because of things like links being embedded, which I feel could cause difficulties when translating to a language where "subjects" "verbs" and "adjectives", for example, don't go in the same order.
ie. The green car = El coche verde in Spanish. If we translated each word as a separate fragment, our translation would yield "El verde coche"

[ryancreatescopy]

This is a really good point @wackerow — ideally we shouldn't have links in the middle of sentences if they require a separate string. I've tried to do that as much as possible with links like "More on X" coming at the end of paragraphs rather than in the content itself, but have definitely slipped into bad habits in the last few pages.

I wonder whether the crowdin software can do anything fancy to prevent this from happening though (as translations have been passing review). Or have we not translated a product page with this problem yet? @sorumfactory can you shed some light on this?

If not, I'm sure we can tweak the content on these pages to make sure we remove in-content links so that they're at the end of sentences on product pages. However this will be really difficult for pages like "glossary" and our "docs" — maybe it's not a problem in markdown files 🤞

[samajammin]

Ya great point @wackerow - thanks for weighing in.

I wonder whether the crowdin software can do anything fancy to prevent this from happening though

I highly doubt it. There's only so much the software can do. At the end of the day, it's volunteers translating string fragments, which I agree is problematic if the main subject/verb/adjective is taken out of context from the sentence.

In terms of providing the actual link, which approach do we think is best?
A) Have the entire sentence be a link
B) Add a phrase after the sentence (e.g. "click here", "read more")
In other situations I would have SEO concerns about option B) - generally the anchor text of links should include relevant keywords to help provide context on what a page is about - but given SEO rankings are not much of a concern I think I'd be fine with that approach. Perhaps there's some additional context we could add as well, e.g. "More on wallets".

[ryancreatescopy]

We'll add a phrase at the end of sentences, but will try to avoid generic links like "click here" or "read more".

[samajammin]

One more consideration (which I suspect is less important) - do we suspect that capitalization may impact translations in any way? e.g. there's phrases in en.json like "Cookie Policy" - would that be interpreted different from "cookie policy" (maybe that's a bad example... would any actually matter)?

If so, we could roll out a standard here for how the strings are stored in JSON. JavaScript can do the work to change a string into Title case or Sentence case depending on the context.

[ryancreatescopy]

I guess that would be up to the translator based on the context. That wouldn't break meaning in the same way as translators can capitalise/un-capitalise if necessary. I'd question whether that JS would be needed. But will defer to @sorumfactory expertise here.

[wackerow]

@samajammin I was thinking about the capitalization too... some languages it flat out won't matter because there are no cases (ie. Japanese).

I don't see it "breaking" translations, but did have a thought about standardizing capitalization a little. I have a branch I was working on yesterday that simplified a couple of the "ALL CAPS" en.json entries...
(tl:dr - CSS text-transform: uppercase;)
My thought was it's probably the simplest to make en.json entries naturally cased with capitals only at the beginning of a sentence or proper nouns, but to leave further styling to the CSS. This way the interpreter doesn't need to consider these things, and if we enter "HELLO" in the english file, and someone translates to "Hola", this could be difficult to catch. Standardizing to use CSS to style seems most appropriate in my opinion, and would override the individual translations. That way "Hello/Hola" could be styled to "HELLO/HOLA" as needed without changing the translation file, so these could be reused elsewhere as "Hello/Hola" again easily.

(Like I said, this is already on a branch locally for me to test, I'm happy to put it in a PR, or just merge it into this one, if you'd like like the idea)