Possible to split build by language?

[hamishwillee]

My library takes about 4 minutes to build on Jenkins with 1 translation, about 10 with 2, about 22 with 3. I.e. the build time taken is non-linear.
When I tried 4 translations it takes over an hour and Jenkins decides it has stalled. It is likely that one day I might need many more translations.

Is it possible to build each language separately?

My thinking is that you should be able to do do so with some thought in your configuration file. The problem would be that the builds would be separate, so you would have to add your own inter-language linking.
Has anyone done this? Are there any other options?

[brc-dd]

How many pages does your site have? You should be able to build over 1000 pages in 4 minutes.

[hamishwillee]

1. Full disclosure, above numbers were for vuepress. On vitepress I can build English and 2 translations in 9 minutes in a github action. I haven't tried the extra translation yet.
2. But the problem is that it doesn't scale with number of translation - so even if I migrate to vitepress and build this time, I'm going to have problems with either the next or the one after (this is one reason I posted that issue about supporting fallback if a translation does not exist - that would give me a huge reduction in pages)
3. The English version has around 870 pages. So with two translations we're up to 2402.

So being able to fallback to English if there is no translation would help a lot, but eventually I might still have to split the build.

[brc-dd]

So, if you have like 8 such translations, it will take about half an hour. If that's not reasonable, maybe you should consider some other framework like Nuxt which support hybrid/on-demand rendering. You won't be able to statically host it though.

[hamishwillee]

@brc-dd Are you telling me that on Vitepress the time/resource cost of adding a translation is linear? IF so, then that's fair. On English + 3 translations Vitepress takes 11.5 minutes, which is not so bad (as you say). If the PR for fallback to English translation under /en goes in things get even better since most translations are not "full".

I like static sites, and I like vitepress. I'll migrate to something else if I have to, but hoping I don't need to. Looks like good for another year or so at least :-)

[brc-dd]

the time/resource cost of adding a translation is linear?

I haven't analyzed it yet, but IMO time should be less than quadratic if not linear. Memory should be nearly constant after a limit.

If the PR for fallback to English translation under /en goes in

That PR (#3312) doesn't work properly. I'll think about it.

Looks like good for another year or so at least

In one year or so, the performance would be much faster because of rolldown. We can also explore splitting by language but that's won't affect CI time I guess because all files would need to be built anyway - doesn't matter if you do it in one go or in batches.

[hamishwillee]

Thanks very much.

We can also explore splitting by language but that's won't affect CI time I guess because all files would need to be built anyway - doesn't matter if you do it in one go or in batches.

If memory is near constant and the time is "more or less" linear that's about as good as I can hope for in the short term. The benefit of splitting by language is not the total time for CI, but the fact that language builds can be deferred and only done if there are changes.

A real benefit here is that translations often break the build, so just being able to build English and the ones that don't fail would be good. [FYI only - The reason they break the build is that I'm using Crowdin for translation, and sometimes translators don't get the placemarker tags like <0>some text</0 > right - in that case there is a space in the end tag. The result is mismatched HTML tags, which vitepress can't cope with].