search

expressjs / expressjs.com

https://expressjs.com
Other
5.26k stars 1.48k forks source link

heads up: Potential Shift to Machine Translations on the Horizon #1676

Open UlisesGascon opened 3 weeks ago

UlisesGascon commented 3 weeks ago

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

Current Situation

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 commented 3 weeks ago

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 commented 3 weeks ago

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 commented 3 weeks ago

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 commented 3 weeks ago

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 commented 3 weeks ago

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 commented 3 weeks ago

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 commented 3 weeks ago

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 commented 1 week ago

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