We recently shipped the groundwork for internationalizing Forem. Initially, this means that admins can set the default locale for their Forem in case it’s primarily targeted for Spanish or Portuguese communities. In the long run, it’s likely that individuals will be able to set the display for all their Forems to override the default settings.
But let’s not try to do all of that at once.
For now, we are accepting iterative improvements to our internationalization.
How to Contribute to Forem Internationalization Right Now
We currently support just two languages during this initial build stage: English and French. Adding many additional languages will be very possible once we get more of the infrastructure in place, but contributions to add a new language are not what we are looking for right now, as opposed to contributing to turning hardcoded english copy into translatable variables.
Example Contribution
We won’t have an individual issue for every possible translatable area, because most of the challenge is discovering a translatable element.
You can see the French version of DEV by visiting dev.to/locale/fr
to get a sense of how this works in production. We are not expecting admin-defined copy to be translatable, but we do expect application-defined copy to translate.
From my knowledge of the codebase, I can visit the French home page and spot some non-translated copy.
I searched through the project and found that that this code is available at app/views/layouts/_main_nav.html.erb
...
<nav class="mb-6 <% unless user_signed_in? %>mt-4<% end %>" id="main-navigation" aria-label="<%= community_name %>">
<ul class="default-navigation-links sidebar-navigation-links spec-sidebar-navigation-links">
<li>
<a href="<%= root_path %>" class="crayons-link crayons-link--block">
<%= inline_svg_tag("twemoji/house.svg", class: "crayons-icon crayons-icon--default", aria_hidden: true) %>
Home
</a>
</li>
<li>
<% unless user_signed_in? %>
<a href="<%= sign_up_path %>" class="crayons-link crayons-link--block fw-bold">
<%= inline_svg_tag("twemoji/handshake.svg", class: "crayons-icon crayons-icon--default", aria_hidden: true) %>
Sign In/Up
</a>
<% end %>
</li>
<% default_nav_links.each do |link| %>
<%= render "layouts/sidebar_nav_link", link: link %>
<% end %>
</ul>
</nav>
This is where it gets interesting. In part of the translation journey, we welcome opportunities to simplify in the name of translation — this is easier for me to say as an owner of the project, but I really think we can get rid of that Sign In/Up
button altogether. It's literally right below the same call to action above.
So I have identified an opportunity for two adjustments:
- Translate "Home".
- Remove
Sign in/Up
altogether.
Our team may disagree with the removal of Sign in/Up
, but as long as it is a small change, I think it's okay to find out about that at the time of the pull request review. We might just ask that you not change that and only modify "Home" — but we shall see. There is a lot of nuance in open source.
Here is my adjusted file:
<nav class="mb-6 <% unless user_signed_in? %>mt-4<% end %>" id="main-navigation" aria-label="<%= community_name %>">
<ul class="default-navigation-links sidebar-navigation-links spec-sidebar-navigation-links">
<li>
<a href="<%= root_path %>" class="crayons-link crayons-link--block">
<%= inline_svg_tag("twemoji/house.svg", class: "crayons-icon crayons-icon--default", aria_hidden: true) %>
<%= t("core.home") %>
</a>
</li>
<% default_nav_links.each do |link| %>
<%= render "layouts/sidebar_nav_link", link: link %>
<% end %>
</ul>
</nav>
Notice that I replaced "Home" with <%= t("core.home") %>
. t
is a Rails view helper that is short for I18n.translate
...
That is everything you need to do in the view, but your work is not done!
Change the localization YAML files, like such...
# config/locales/en.yml
en:
core:
.....
home: "Home"
# config/locales/fr.yml
fr:
core:
.....
home: "Page D'Accueil"
Values in these files should be alphabetical.
"Home" literally translates to "domicile", or maybe "maison", but in the context of the Internet, I believe "Page D'Accueil" is appropriate.
We are still in the initial infrastructure stages of this project, so we don't yet need to be perfect on all translations. Do your best. This is why we're not immediately expanding beyond our test languages of French and English.
That's it! If you made the above PR, we would probably accept it. Please read our docs to better understand how to contribute in different ways, and look forward to more posts about how to contribute to I18n as this part of our project evolves.
🤓 Full instructions are in our docs I18n docs.
🍂 More Forem issues marked as Hacktoberfest-eligible
Happy coding!
Top comments (13)
Here is a live PR example I just tossed up — different from what I walked through in the post. That is still up for grabs at the time of writing this.
Translate notification filters #14884
What type of PR is this? (check all applicable)
Description
This follows existing patterns of internationalization to translate the filters on the notifications page.
The only added translation is "All".
The use of
pluralization
is following existing patterns. This may not be the most scalable as we broaden translations, but I think appropriate for now.Related Tickets & Documents
dev.to/devteam/forem-hacktoberfest...
QA Instructions, Screenshots, Recordings
Added/updated tests?
Great initiative! We recently wrapped up a massive internationalization project at my work, and I'd love to contribute to translating DEV ❤️ I was wondering: do you have any rules around structuring your yml files? We broke our tokens up into flows/areas of the app, and we had a strict rule around not having too many nested levels (no more than 3), to keep things clean and easy to read. Have you thought about any rules for that?
We have not yet strictly defined these rules or properly had the discussion yet internally, but I anticipate us landing on these types of rules. For the time being, use your judgment and influence us towards a good decision with good clean PRs — which I see you are already doing.
Once we make some choices here, I think we should comment the rules and principles right in the locale files to complement the docs and keep people informed as anything changes. So keep checking in, and your contributions are very much welcome!
Hey Ben! this is quite interesting, i'd love to contribute to translating DEV to Indonesian! do you think it's possible?
Once we get more of the variables in place we’ll start accepting specific languages. So please start by finding some hard coded English and change it to an i18n variable.
Thank you! i'll look up to the code!
Hi @hasobi let's get in touch. I also thinking to contribute on Indonesian support lang after some backbone of I18n.
Do you have Rails experience?
Yay! Awesome Ben! I'll be helping to translating into Portuguese! Forking as soon as possible to help it out!
Awesome! Portuguese translations will be very helpful!
At this very moment we're mostly looking for contributions which uncover un-translated templates and remove hardcoded copy with variables, but we will very soon graduate to wanting to expand language lists.
My intentation it was to schedule a call meeting with you to see a good way how can I help you to translate dev.to website to Portuguese and make good engagements here in Brazil. If you want to, reach me out here or twitter: @glaucia86 (I work as Cloud Advocate at Microsoft)
Hello ben,
I'm Ready to volunteer as translator.
I'm native arabic speaker and i can spare sometime during the day to translate forem.
Please share with me the link to your weblate or any other service and i can start from tomorrow.
Meanwhile can please also tell me if the RTL is supported through the current status?
Can't wait!
What’s the current status of the i18n work and what’s still on the i18n roadmap?