publicdata/j40-cejst-2
1
0
Fork 0
mirror of https://github.com/DOI-DO/j40-cejst-2.git synced 2025-09-01 04:30:58 -07:00
Code Issues Projects Releases Packages Wiki Activity Actions
j40-cejst-2/client
History
Nat Hillard 16a9e67db0
 Static Deploy to Github Pages (#73) 
Addresses #58 , "As a member of the public, I want to see J40's website live on the internet, so that I know it's real!" - hosting on github pages for now as a temporary measure. This fix does NOT: 1) add .gov domain hosting, or 2) post to the geoplatform s3 bucket. This will need to happen in a subsequent fix. 

The changes made specifically to enable this for now:
* Adding github action to build, test, and deploy on pushes to client/
* Adding path prefix to build gh-pages at https://usds.github.io/justice40-tool/
* (Temporarily) pointing to fix branch for trussworks to enable SSR building
* Removing the workaround for the above bug in gatsby-node.js
* Setting build target to be 14.x due to version number limitations
* Adding gh-pages dependency, deploy action for manual deploy
* Force renaming J40header -> J40Header and J40footer -> J40Footer due to Linux case sensitivity
2021-05-25 12:07:45 -04:00
..
.vscode Typed Sass Styling (#69) 2021-05-20 23:59:20 -04:00
src Static Deploy to Github Pages (#73) 2021-05-25 12:07:45 -04:00
.gitignore Informational Site: Initial Gatsby Init (#62) 2021-05-19 18:19:38 -04:00
gatsby-browser.js Adding Trussworks USWDS React Wrapper (#67) 2021-05-20 21:54:08 -04:00
gatsby-config.js Static Deploy to Github Pages (#73) 2021-05-25 12:07:45 -04:00
gatsby-node.js Static Deploy to Github Pages (#73) 2021-05-25 12:07:45 -04:00
package-lock.json Static Deploy to Github Pages (#73) 2021-05-25 12:07:45 -04:00
package.json Static Deploy to Github Pages (#73) 2021-05-25 12:07:45 -04:00
README.md Addresses part of #16, (#71) 2021-05-21 13:05:27 -04:00
tsconfig.json Informational Site: Typescript (#63) 2021-05-19 18:55:10 -04:00

README.md

Justice40 Client

Localization

About

This project uses Gatsby Plugin Intl to manage internationalization and localization.

There are a number of components to this, but for the purposes of localization, this utizes the popular react-intl package from FormatJS.

This works by directing users to a locale-appropriate version of the page they wish to visit based on their browser settings, populated automatically at build time by the contents of json files in the src/intl directory.

Writing

For this library to work optimally, the following principles should be obeyed (see here for more detail):

  • All user-visible strings should be wrapped with the intl.formatMessage function or the <FormattedMessage> tag, with a description and defaultMessage set. Do not yet set the "id" tag, it will be generated for you. To generate files for localization, run npm run intl:extract to update the file at src/intl/en.json with the extracted contents of all FormattedMessage components.
  • Take note of the id in this file, and add this back as a parameter of your function/prop for your component (this is done to avoid naming collisions as detailed here)
  • All Link components should be imported from gatsby-plugin-intl instead to get the locale-appropriate link
  • All pages should import and use useIntl from gatsby-plugin-intl

We will later add integration with Github Actions to ensure that all messages have been formatted as a condition/check for committed code.

Translating

From there, send src/intl/en.json to translators. (Depending on the TMS (Translation Management System) in use, we may need a different format, so we can alter the settings in package.json if needbe). When they return with the other language file, e.g. es.json, place this in src/intl/ as a sibling to en.json.

Consuming

React-Intl works according to Google SEO best practices by creating locale-specific URLs.

To access a translated version of a page, e.g. pages/index.js, add the locale as a portion of the URL path, as follows:

  • English: localhost:8000/en/, or localhost:8000/ (the default fallback is English)