Use Spanish translations in the UI #66
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
oyamauchi
force-pushed
the
owen.setlocale
branch
from
92d7cd9
to
cb3f239
Compare
❤️ |
|
This is great! I'm wondering if the |
RandomEtc
approved these changes
Nov 15, 2023
|
Hmm the Cypress runs sometimes fail (they time out waiting for the Parcel build to complete), but I'm only seeing this on CI. Will keep looking into it. |
oyamauchi
force-pushed
the
owen.setlocale
branch
from
4b61eb2
to
26c22da
Compare
oyamauchi
force-pushed
the
owen.setlocale
branch
from
26c22da
to
8503067
Compare
## Description Finally we're here: you can just set `language="es"` on the calculator element and it'll be in Spanish. Getting the strings out of the XLIFF file and into code requires running `lit-localize build`. Rather than making people do that manually, I wrote a Parcel resolver that runs the command behind the scenes. Overengineered? Maybe! But I learned a bunch about Parcel! Note about switching `language` dynamically. Apart from the problem I noted in the comment on the `language` attribute (text that came back from the API will not change language until the next API fetch), there's another problem, with the Shoelace select elements: the text shown in them won't change until you make a new selection in the element. I _think_ it may be related to [this](shoelace-style/shoelace#1570); in any case, once all the immediate i18n work is wrapped up I may try to isolate the issue and file an issue with them if it's not the same bug. With this bug, dynamically setting the attribute _on page load_ will leave a couple of untranslated strings, and I think that's a use case we do want to support. ## Test Plan Add a `language="es"` attribute to the main element in `rhode-island.html`, and make sure the UI shows up in Spanish. Query for incentives; make sure the program names of federal incentives show up in Spanish. (Those are the only thing localized on the backend right now.)
I think the generated files being modified by `lit-localize build` was causing Parcel to rebuild in an infinite loop. There seems to be no real way to exclude files from Parcel's watcher in `serve` mode, so I'm doing so in a very hacky way: putting the generated strings files in Parcel's cache directory.
oyamauchi
force-pushed
the
owen.setlocale
branch
from
8503067
to
dc6c05b
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
Finally we're here: you can just set
lang="es"on the calculatorelement (or any ancestor element!) and it'll be in Spanish.
Getting the strings out of the XLIFF file and into code requires
running
lit-localize build. Rather than making people do thatmanually, I wrote a Parcel resolver that runs the command behind the
scenes. Overengineered? Maybe! But I learned a bunch about Parcel!
Note about switching
langdynamically. Apart from the problem Inoted in the comment on the
langattribute (text that came backfrom the API will not change language until the next API fetch),
there's another problem, with the Shoelace select elements: the text
shown in them won't change until you make a new selection in the
element. I think it may be related to
this; in any
case, once all the immediate i18n work is wrapped up I may try to
isolate the issue and file an issue with them if it's not the same
bug. With this bug, dynamically setting the attribute on page load
will leave a couple of untranslated strings, and I think that's a use
case we do want to support.
Test Plan
Add a
lang="es"attribute to the main element inrhode-island.html, and make sure the UI shows up in Spanish. Queryfor incentives; make sure the program names of federal incentives show
up in Spanish. (Those are the only thing localized on the backend
right now.)