Add mini react-intl i18n implementation. #375
Conversation
Add a mini internationalization implementation to the default itinerary changing the mode names, mode separator, the time format and the duration format. At the moment only english (en-US) and french (fr-FR) translations are provided and more languages will be added in later pull requests.
lib/util/i18n.js
Outdated
| // (We cannot really load languages on demand using fetch... that would require tinkering with mastarm build, | ||
| // so here we build an index of translated messages.) | ||
| const translatedMessages = { | ||
| 'en-US': require('../../i18n/en-US.yml'), |
There was a problem hiding this comment.
One thing that stands out to me here is that we may need to sub out these strings on a per-implementation basis. E.g., the names of otp modes in Portland OR may be different than in Atlanta (e.g. light rail vs streetcar for TRAM). Not really a requirement for right now, but any ideas for this at the moment?
There was a problem hiding this comment.
I agree that this is needed, but think it'd be better to figure this out now rather than later. Also, I think it should be possible to load language files on-demand using fetch - the app should just wait until the base language file is loaded before the first main render. I think it'd make a lot of sense to have some kind of config file that can be used to override a default set of language files, however that process would likely be part of the trimet-mod-otp project (at least until we merge those two projects together).
| locale: getUrlParams().locale || 'en-US', | ||
| userLanguage: state.user.loggedInUser == null ? 'en-US' : state.user.loggedInUser.language, | ||
| use24HourFormat: state.user.loggedInUser == null ? false : state.user.loggedInUser.use24HourFormat |
There was a problem hiding this comment.
These all deserve a little more thought on how they are derived. I think a good place a lot of this could live is somewhere in the ui object in the redux state. Even if a user has a default language or time format they might still want to change it to some other language.
There was a problem hiding this comment.
See various comments, most of them are blocking. I think this is a good first demonstration of how things could work, but the overall structure of where the translations are loaded from and then stored in the redux state needs a more comprehensive design that will work everywhere else.
Restructuring language yml files, adding currency based on config settings, storing locale settings in redux store
landonreed
changed the title
Move IntlProvider to responsive webapp class from redux state and flatten messages to be used in components.
|
|
||
| const mapStateToProps = (state, ownProps) => { | ||
| return { | ||
| currency: state.otp.config.localization?.currency || 'USD', |
There was a problem hiding this comment.
Should this not be derived from GTFS or the relevant GBFS (or other) providers? I'm not sure if there's a strong justification as to why we need this property.
There was a problem hiding this comment.
We are displaying a cost line item for car-only, walk-only and own-bike-only itineraries, even if no transit itinerary is found and the cost shown is $0.00. We need an "ambient" currency that we don't know otherwise if no transit itinerary is shown.
The alternative is to not show the cost item if itinerary.fare is not set. Thoughts?
There was a problem hiding this comment.
@landonreed says
Ah, yea, good point, Binh. I'm fine with the ambient currency. That's helpful info that might be useful to throw into a comment though.
Comments regarding this added in 9b7d311.
|
Adding the Blocked label, I would prefer we cut a release of OTP-RR before we start adding the internationalization features. |
binh-dam-ibigroup
removed
the
BLOCKED
|
🎉 This PR is included in version 3.2.0 🎉 The release is available on: Your semantic-release bot 📦🚀 |
Fixes potential regression in #375
Add a mini internationalization implementation to the default itinerary changing the mode names,
mode separator, the time format and the duration format. At the moment only english (en-US) and
french (fr-FR) translations are provided and more languages will be added in later pull requests.
Translated messages are defined in language-specific yml configuration files (e.g. en-US.yml) and all language yml files are loaded as dynamically assigned file names are not compatible with node.js.
For future development, the language setting is retrieved from the URL param 'locale' and may be used to change the displayed language.