Hacker News Reader

Comment by haizzz | Hacker News Reader

Hey everyone, author here, the article is a bit misleading in that .xlf files aren't really generated files, they're created through our translation pipeline by real humans. I considered them generated in the sense that they're not directly worked on by engineers who have to deal with them in the repository.

The content of these translation files are snapshot in time aligned with the text in our product so simply removing them we would lose all the changes made to translations each time texts are changed.

Sorry about that, hope this clears it up!

Edit: for more information on translation and xlf files, we have another blog post all about them https://canvatechblog.com/how-to-design-in-every-language-at...

View on HN

Can't those xlf files be stored in a separate repo or in an object storage and let the build system fetch them from there?

That wouldn't be called a "monorepo" then :D

Obviously, the problems they are solving (and admitting to solving) are due to their dedication to the monorepo.

With all the effort spent on working around the drawbacks, I really wonder what advantages they are seeing that make it worth their while?

Well, there is monorepo and monorepo. Git was primarily made to host code, not necessary artifacts. I would categorize those files as artifacts and in my opinion it would still be a code monorepo to have everything else on a single repo.

They are code files managed by a different set of people (translators), not generated artifacts (as they explain elsewhere in this discussion).

If we are being pedantic, git was not designed to host multiple projects in a single repo (otherwise, git would have been a subdirectory in the kernel tree). But tools are made without knowing how they'll be used, and that's ok, so I wouldn't stress on what the purpose for monorepo was, but how it's used and what value it brings.

>They are code files managed by a different set of people (translators), not generated artifacts (as they explain elsewhere in this discussion

Translations do not look like code to me. Rather human generated artifacts.

What I understand is there is a strong tie/match needed between versions of these translations files and the code itself, so I believe this is where having all in the same repo would make sense, having the translators update those file when code has been modified...

I think it's relatively normal to include build artifacts in a monorepo when you don't want users to have to be able to build every single one. Especially if you don't want to have to buy a license for every developer for specialist software that only needs to be used by a few people.

Given the religious nature of the "monorepo" vs. "not-monorepo" argument, I would venture a guess that suggesting storing these xlf files elsewhere would upset someone's notion of what a "monorepo" Should Properly Be.

Having them under version control seems very important. Monorepo makes that easy

Thanks for additional info. I'm happy to hear that localization is on your priority.

> English source strings used in our frontend code live in Typescript files (.messages.ts). Source strings used in our backend code live in Java files (Message.java). Our internationalization (i18n) pipeline converts this into a series of XLIFF files (ending in .xlf), with one file for each locale. All these files live in the repository, but the translated .xlf files should never be modified by hand since they are updated automatically when strings get translated.

Isn't it cache?

Not quite, the .messages.ts and Message.java files are only in English which are then converted into XLIFF files for other languages so they're the source of truth for what the string should be in different locales so they're not cache

If it is output of some other tool, then it is a build artifact and there is no need to check it in.

I have this argument with people all the time and the conclusion is always like: "it is too hard to integrate the generator with the build system so we check them in".

The big problem with generated files is merge conflicts. How do you resolve a merge conflict on generated files. especially if they are binary.

Reply on news.ycombinator.com