heads up: Potential Shift to Machine Translations on the Horizon

[UlisesGascon]

In the last TC meeting, we discussed the future of translations. Here are some notes:

Current Situation

• Translations are quite outdated across all languages.
• Currently, we rely on the community for translation efforts.
• There are instances where users encounter outdated information on the website, which can lead to frustration.
• We are planning to migrate the website, and updating/moving translations will add a significant workload when we release the content.

Proposed Solution

The idea is to explore using automated translations by default (machine translations). This would require some effort to build the CI system and ensure that the English version of the documentation is optimized for machine translation (plain English, simplified structure, etc.).

This approach could greatly simplify the migration, as it allows us to focus on i18n support rather than handling both translation and content migration.

Of course, we would still enable the community to tweak and improve translations as needed. This way, we can continue providing high-quality documentation for everyone.

Let’s Discuss

What do you think? (@crandmck, @expressjs/docs-wg, and @expressjs/express-tc)

Additionally, I wonder if we should consider freezing translation efforts for now (such as issues like #1480, #1553) and redirecting that team’s efforts toward planning the future website so we can kick that off in 2025.

[chrisdel101]

Assuming the translations themselves are adequate this seems like a good idea since many translations are missing items, and as you said, some might have incorrect info. I'd be nice to have continuity across the translations, with all of them having the same links and pages in their languages.

At least the look of the home pages are consistent due to #1568.

Was there any idea of what changes would be needed to make this work? I wonder if this work can be bundled with any site restructuring that @bjohansebas has mentioned wanting to do in passing. (Thinking he meant like more flexbox and page containers if I understood?)

What format would the translations provide? Could it be like Json? If it's running in the CI and would run every build, and gave json (or some other data) it would be amazing if it was possible to have only a single site markup! Instead of a separate one for each language. And inject the json into the page markup at build time!
Just my two cents...

[bjohansebas]

I'll leave my thoughts and questions here later, but I think #1553 could move forward since the PR is ready and we just need to add the PAT, while #1480 needs a bit more research, so it would be better to freeze it for now, if that sounds good to you.

[crandmck]

I think it's a good idea in general. The existing localizations are so inconsistent in both extent and quality that starting over (as it were) makes more sense, especially with the quality of machine translation today.

I wonder if we should consider freezing translation efforts for now

Yes, we shouldn't spend any more time/effort on stuff that will just get thrown away.

We should also provide some notice or guidance to the community of our intent and that we're freezing localization efforts as we work in this direction (e.g. we don't want any translation contributions, etc.).

[UlisesGascon]

We should also provide some notice or guidance to the community of our intent and that we're freezing localization efforts as we work in this direction (e.g. we don't want any translation contributions, etc.).

We should include a message in the README.md and rewrite the https://github.com/expressjs/expressjs.com/blob/gh-pages/CONTRIBUTING.md#contributing-translations ?

[bjohansebas]

I think this will be a great addition. As mentioned, there is quite a bit of inconsistency in the page translations, so automating this will be fantastic. There are some AIs that do this well, like Cohere or ChatGPT. This will also help in the future when migrating the site to newer technologies that offer a better developer experience

Was there any idea of what changes would be needed to make this work? I wonder if this work can be bundled with any site restructuring that @bjohansebas has mentioned wanting to do in passing. (Thinking he meant like more flexbox and page containers if I understood?)

The design and code of the site won’t be affected here, the focus will be solely on translations. So, that work is a separate matter, but they go hand-in-hand to improve the documentation.

We should include a message in the README.md and rewrite the https://github.com/expressjs/expressjs.com/blob/gh-pages/CONTRIBUTING.md#contributing-translations ?

Yes, we should update the contributions. Should this be integrated into #1671, or would it be better in a separate PR?

[chrisdel101]

I can add something to #1671? I'm thinking I will leave the documentation for how to contribute translations as it is, but add a header that says that we are moving in this direction, and we are pausing translation work temporarily, or something.
If/when we finalize the machine solution, we can then remove the sections completely.

(I'm going to go ahead and add this. It can always removed or changed before merge.)

Or I can remove the translations sections entirely now? But it seems better to wait on removal and just apply the brakes for now.

[carlosstenzel]

I can add something to #1671? I'm thinking I will leave the documentation for how to contribute translations as it is, but add a header that says that we are moving in this direction, and we are pausing translation work temporarily, or something. If/when we finalize the machine solution, we can then remove the sections completely.

(I'm going to go ahead and add this. It can always removed or changed before merge.)

Or I can remove the translations sections entirely now? But it seems better to wait on removal and just apply the brakes for now.

I like the idea of ​​having this information on the pages. Good idea

[bjohansebas]

I understand that translation efforts are currently paused, but are grammar corrections still being accepted?

[bjohansebas]

It might be a good idea to use Crowdin, as it is used by Node.js and Electron on their website, and it's really good. Since Express is an open-source project, it's free (if we request the license).

[carlosstenzel]

It might be a good idea to use Crowdin, as it is used by Node.js and Electron on their website, and it's really good. Since Express is an open-source project, it's free (if we request the license).

I like the idea