[roflulz]

monorepo until it becomes too big -> then, splitting it into 2-3 repos, until each one also gets too big to manage...

[masklinn]

The problem is not the repository, it’s having the translation data in the repo.

We have the same issue at $dayjob, the repo is quite large and 80% of it is translation data. Even if they compress ridiculously well (99% last I checked) the number of translation files and the number of exports makes them the vast majority of the cost.

However that structure remains a convenient nuisance, and more importantly removing them would really only be useful if we rewrote the entire repository, which breaks all working copies.

There’s been a task in a wishlist for years now, but the business incentive just isn’t there.

Exit: actually the translation files are 80% of the working copy, they’re closer to 90% of the repo, and on the far side.

[andi999]

But isnt it sort of correct to have translation data, which is text data, and there might be bug fixes, in the repo?

[masklinn]

Which is why it commonly is there, but at the same time the translation data is kinda independent: you can run the software with no or part of the translations, as far as the software is concerned it’s usually close to configuration data or assets.

Not to mention transgressions often have their own lifecycle e.g. is common to find translatable strings which are untranslated or incorrectly translated, and want to ship updates independently from the software’s.

As such keeping the translations outside the source is also perfectly defensible.

[klysm]

Yes

[MisterTea]

> The problem is not the repository, it’s having the translation data in the repo.

Does this data change as often as the code does? If not then get it out of the repo.

[andi999]

What if it changes more often than the code? Throw out the code?

[pessimizer]

There's no material difference between taking the translations out of the repo and taking the code out of the repo. "She shouldn't divorce him, he should divorce her!"