Research solutions for localization

a24vinla commented

2026-04-17 08:31:28 +00:00

Collaborator

No description provided.

a24vinla added the

research

label

2026-04-17 08:31:28 +00:00

c24danli was assigned by a24vinla

2026-04-17 08:31:58 +00:00

a24timsv referenced this issue

2026-04-17 08:32:30 +00:00

Cleanup wrong language in code #392

c24danli commented

2026-04-17 15:46:28 +00:00

Collaborator

Option:1

React's Context API
Using Reacts' Context API (createContext, useContext) a language can be set to English/Swedish and stored globally in <App>.
Child components and views can then access the current language and use a translation file in that view/component to get the correct text

positives

No external dependencies needed
Full Control
No extra functionality that we dont use gets implemented, making it lightweight.
Each view can have its own translation file

Negatives

Setup needed, Context API is well documented but there are fewer examples of using it specifically for translation compared to other common libraries. The implementation pattern is similar to light & dark mode.
You must implement advanced features yourself:
- pluralization
- interpolation ("Hello {name}")
- formatting (dates, numbers)

Overall

If we just use it for choosing between translation outputs and do not intend to implement many languages, it is a good choice.
If a lot of formatting (numbers, dates) and interpolation (adding variables to strings) occurs, then more work is required.

### Option:1 _React's Context API_ Using Reacts' Context API (createContext, useContext) a language can be set to English/Swedish and stored globally in `<App>`. Child components and views can then access the current language and use a translation file in that view/component to get the correct text ### positives - No external dependencies needed - Full Control - No extra functionality that we dont use gets implemented, making it lightweight. - Each view can have its own translation file ### Negatives - Setup needed, [Context API is well documented](https://legacy.reactjs.org/docs/context.html) but there are fewer examples of using it specifically for translation compared to other common libraries. The implementation pattern is similar to light & dark mode. - You must implement advanced features yourself: - pluralization - interpolation ("Hello {name}") - formatting (dates, numbers) ### Overall If we just use it for choosing between translation outputs and do not intend to implement many languages, it is a good choice. If a lot of formatting (numbers, dates) and interpolation (adding variables to strings) occurs, then more work is required.

c24danli commented

2026-04-20 09:14:12 +00:00

Collaborator

Option:2

i18next/react-i18next
react-i18next is a library that builds on i18next and uses React’s Context API internally, similar to Option:1, with the difference that the functionality is pre-made for ease of use. In the Github repo we can see that it has the MIT license, a large pool of contributors, and an average of 11 million downloads per week, making it a well-tested and widely used library.

Positives

Used extensively, meaning many examples and documentation exist
Advanced feature implementation exists:
- pluralization
- interpolation ("Hello {{name}}")
- formatting (dates, numbers)
- lazy loading
Each view can have its own translation file
Scales better with many languages

Negatives

Might be too big for our needs (in terms of extra functionality)
External dependencies needed
Setup needed. Documented on the official site and many unofficial sites with exampels

Overall

It is well tested and widely used, and if many languages and advanced functionality are required, it is a good choice.
However, depending on usage, it might become too large for what is required.

### Option:2 **i18next/react-i18next** react-i18next is a library that builds on i18next and uses React’s Context API internally, similar to Option:1, with the difference that the functionality is pre-made for ease of use. In the [Github repo](https://github.com/i18next/react-i18next) we can see that it has the MIT license, a large pool of contributors, and an average of 11 million downloads per week, making it a well-tested and widely used library. ### Positives - Used extensively, meaning many examples and documentation exist - Advanced feature implementation exists: - pluralization - interpolation ("Hello {{name}}") - formatting (dates, numbers) - lazy loading - Each view can have its own translation file - Scales better with many languages ### Negatives - Might be too big for our needs (in terms of extra functionality) - External dependencies needed - Setup needed. Documented on the [official site](https://react.i18next.com/latest/using-with-hooks) and many unofficial sites with [exampels](https://medium.com/@xbstrxct/localization-in-react-best-practices-e38dee708aae) ### Overall It is well tested and widely used, and if many languages and advanced functionality are required, it is a good choice. However, depending on usage, it might become too large for what is required.

c24danli commented

2026-04-20 09:19:07 +00:00

Collaborator

Might add other options and keep adding to the once existing is later stages

c24danli added the

needs review

label

2026-04-20 09:19:24 +00:00

b24krila was assigned by b24johka

2026-04-20 13:43:00 +00:00

b24krila commented

2026-04-20 14:13:11 +00:00

Collaborator

The research is good overall, the trade-offs are well explained and the main decision point seem to be whether we expect translation to grow more complex over time. Since that will largely determine whether we should choose a lightweight context API solution or if a more complete library like react-i18next is better.

The comparison makes it clear that option 1 is better for simplicity and control while option 2 would reduce the maintenance risk in the future by handling common i18n concerns such as pluralization, interpolation, formatting, etc.

This might be something that should be brought before the customer such as issue: #402. Since in option2 we need to introduce external dependencies which could be a factor in the requirements.

The research is good overall, the trade-offs are well explained and the main decision point seem to be whether we expect translation to grow more complex over time. Since that will largely determine whether we should choose a lightweight context API solution or if a more complete library like react-i18next is better. The comparison makes it clear that option 1 is better for simplicity and control while option 2 would reduce the maintenance risk in the future by handling common i18n concerns such as pluralization, interpolation, formatting, etc. This might be something that should be brought before the customer such as issue: [#402](https://git.webug.se/Andras/BoundlessFlowCampus2K/issues/402#issuecomment-3779). Since in option2 we need to introduce external dependencies which could be a factor in the requirements.

b24krila added

reviewed

and removed

needs review

labels

2026-04-20 14:13:18 +00:00

~~b24krila referenced this issue 2026-04-20 14:15:02 +00:00~~

Questions for product owner and customer Week 3 #418

b24krila referenced this issue

2026-04-20 14:16:07 +00:00

Questions for product owner and customer Week 3 #418

a24timsv commented

2026-04-22 13:06:45 +00:00

Collaborator

The same answer as in #402, we should decide which one to use depending on an evaluation. It looks like React has built in localization and Henrik was a big fan since it doesn't add any dependencies. Us group leaders will decide this as soon as possible.

a24timsv commented

2026-04-23 11:01:06 +00:00

Collaborator

It seems to use that React has a sort of built-in localization tool (React's Context API) and since we already use React and want as few dependencies as possible we have decided to use it.

When we talked with Henrik we talked about word count for the page. Since it is relatively low and we can translate it ourselves we should use something like a built in system instead of introducing something that can break.

If this turns out to be still a pain to setup even with our low word count we could consider changing to something else.

It seems to use that React has a sort of built-in localization tool (React's Context API) and since we already use React and want as few dependencies as possible we have decided to use it. When we talked with Henrik we talked about word count for the page. Since it is relatively low and we can translate it ourselves we should use something like a built in system instead of introducing something that can break. If this turns out to be still a pain to setup even with our low word count we could consider changing to something else.

a24vinla referenced this issue

2026-04-23 12:27:47 +00:00

Implement Reacts built-in localization #522

a24vinla closed this issue

2026-04-28 08:03:05 +00:00