Shared/common locales location?
mauro-ni opened this issue · comments
Let's suppose to use react-i18next to manage internationalization, where would you put locales files?
Would you put everything in src/locales or instead give each feature its own locales (and maybe use src/locales for shared ones)?
Many thanks in advance for your reply (your time).
Cheers,
Mauro
Hi there!
Repetitive translations can be shared in src/locales.
As for the feature-specific translations, they can live in their corresponding feature folders and utilize the namespaces feature of i18next.
Hi @alan2207, many thanks for your replay.
If I got what you said, then:
Feature a
Locales
src/features/a/locales/en/a.json
src/features/a/locales/it/a.json
Usage
t("a:key") or t("key", { ns: "a" })
Feature b
Locales
src/features/a/locales/en/b.json
src/features/a/locales/it/b.json
Usage
t("b:key") or t("key", { ns: "b" })
But what about nested features? How would you handle them?
Feature b (nested inside a)
Locales
src/features/a/features/b/locales/en/???.json
src/features/a/features/b/locales/it/???.json
Usage
t("???:key") or t("key", { ns: "???" })
How would you replace ??? with?
Many thanks again,
Mauro
Maybe we shouldn't nest features after all. It could make things more complicated in the longer run. I just updated the docs that were recommending it. If you still think it makes your work easier, feel free to nest, but generally, that would be unnecessary.
@alan2207 thanks for the reply.
What about features depending on other features?
From the routing point of view I have situations such
{APP_URL}/a-entities/{id-a-entity}/b-entities/{id-b-entity}/c-entities/{id-c-entity}
I am tempted to organize things in the following way
/src/features/a/features/b/features/c
Is it better to have one one level also in this situation?
/src/features/a
/src/features/b
/src/features/c
What do you think?
Cheers,
Mauro
It really depends on the application.
Imagine a social network where you can have users, posts, images, videos, comments, etc.
If it were required that only posts had comments, then I would probably keep comments as part of the posts feature and not extract them into a separate feature.
But if we were required to have comments for posts, images, and videos, it would make sense to have a comments feature as a standalone feature that is compatible and used with posts, images, and videos.
@alan2207 thanks.
Ok, then I would have only feature A and, in the future, if features B o C are needed elsewhere then I can extract them.
Correct?
Many thanks.
Mauro
Exactly! Start with the main features of your application and put everything related there. Then you can break it up further once you notice something should be extracted. It doesn't need to be used elsewhere to be a feature, but it needs to solve the business problems of the application. I would suggest you check out domain-driven design and development to get more info and develop intuition about when something should be extracted.
Thank you!