Refactor translation system#5753
Conversation
vesameskanen
commented
Apr 16, 2026
vesameskanen
commented
- Get rid of complicated and unnecessary StoreListeningIntlProvider.js
- Split translations to one file per language
- Load only one single language bundle for the current language
- Refactor message bar related utils to use new single language localization
- Remove about 200 unused translations per language
- Remove outdated complicated polyfill code
- Remove some unused styles
- Update unit tests
Messages are not generated from a react component, so hooks can't be used
VillePihlava
left a comment
VillePihlava
left a comment
There was a problem hiding this comment.
- Can you rename the
intlfolder totranslations? Makes a bit more clearer. If theres a good reason to name itintlthen its fine. - I did not look at individual translations files.
- We should update to react-intl version 3. It should be compatible with react version 16. This probably removes a lot of code. I will rereview once this has been done.
| content: translations[key], | ||
| }); | ||
| }); | ||
| geolocationMessages[e] = message; |
There was a problem hiding this comment.
I don't like the mutable state here. How much work would it take to just use the return value from this function?
There was a problem hiding this comment.
In that case the function should be renamed to getGeolocationMessages
There was a problem hiding this comment.
These messages are a global resource which is not used from react components. Messages are built here once.
We could, of course, pass translations and current language to this file and build each message dynamically when needed with a 'getMessage' func, but we still niin the init call to store language and translations for later use.
| messages[key] = { | ||
| id: key, | ||
| persistence: 'repeat', | ||
| priority: 4, | ||
| icon: 'caution_white_exclamation', | ||
| iconColor: '#dc0451', | ||
| backgroundColor: '#fdf0f5', | ||
| type: 'error', | ||
| content, | ||
| }; |
There was a problem hiding this comment.
Again, mutable state vs return value.
| export function failedFavouriteMessage(type, isSave) { | ||
| const t = favouriteTypes.includes(type) ? type : favouriteTypes[0]; | ||
| const key = isSave | ||
| ? `add-favourite-${t}-failed-heading` | ||
| : 'delete-favourite-failed-heading'; | ||
| return messages[key]; |
There was a problem hiding this comment.
If the messages are e.g. put in the global context, then this could be a util function that takes the current set of messages as a parameter
…e state from geolocationMessages and messageUtils. Change how translations are handled.
2 participants
