Syncing upstream changes, tests, and the long term outlook for his fork

[ajbeaven]

I'm midway through a large refactor that involves upgrading our legacy .NET Framework website to .NET Core. We use turqoiseowl/i18n extensively to manage translations as I'm sure you agree, it's by far and away the best approach to localisation available in .NET (massive thanks to @turquoiseowl and @danielcrenna!)

As you know, that repository (which I'll call "upstream") doesn't support .NET Core. This has been a big roadblock in our upgrade pathway so I was relieved to see that this repository existed! Thank you so much the work involved in creating this.

I have come across a couple of bugs early on in my integration with this repository that have thrown up a few questions:

Syncing changes with upstream

Both of these bugs are somewhat related to small disparities between the two repositories. I can understand why this happens since this isn't a direct fork - syncing will be a manual, arduous process going forward. Do you have any thoughts on the viability of a semi-regular sync between these two repositories?

Bringing over the tests

I totally respect the decision to avoid bringing over the bloat that comes with tests from the upstream repo, particularly if the code that is tested there has been unchanged. I suspect though, as time goes on (particularly if regular syncing doesn't occur), the two repositories will diverge to such a point where this approach might not make so much sense. One of the bugs fixed in the PR linked above would have been picked up by the tests in question and more generally, it gives people a lot more confidence to contribute if things are well tested.

What are your thoughts on bringing across any relevant tests from upstream? I know this could mean even more work if you do decide to manually sync the repositories so understand any hesitance to do so.

Long term outlook for this fork

Big thanks to Finter Mobility for sponsoring the work done on this repository and to you @peters for the personal effort you've put in making this all happen. Amazing work; I'm truly thankful. This question is largely related to the extent of this support.

Do you envision all the features available in upstream to eventually make their way over (I'm not yet sure what is not supported)? If this repository became popular, would you struggle to devote time to maintenance/issues/PRs, etc.? I understand these are big, possibly sensitive questions so respect if you simply just don't know or can't give an answer.

Any thoughts or insight would be appreciated!

[peters]

Thank you for your interest in this project. This project has always been a temporary solution for us because we are migrating away from i18n.core to ASP.NET Core Localization (should probably have mentioned that in the README). The reasons why we are migrating away is that that we want to take an ML-based approach for translations and that it's difficult to review pull requests due to noisy diffs in large projects.

You should note that we have been using this in production for 1.5 years now and from my point of view I consider it production quality (for what we use it for).

This is not really a fork per-say because I only cherry-picked the stuff we use internally. The reason why the unit tests are missing is because IMHO they are not in the best shape to begin with.

When we have finished migrating away from i18n.core the plan is to archive this repository. If I where you I would simply fork this project and implement the remaining bits yourself.

[ajbeaven]

Interesting - thanks for that insight. Why do you find the diffs become noisy? Do you commit the .po files to source control?

I'm currently using Loco, a translation management tool to manage the translations. As part of our release pipeline, it pulls in the most up to date translations from that tool and makes it part of the release, so the translations themselves don't muddy the commits.

The thing I love about this repo's approach is that it handles everything at the request level, which makes it so much easier than ASP.NET Core Localization to do things like localization of JS files and such. Anything sent over the wire could theoretically include translatable text. I suppose if that isn't a necessity then it makes sense to use the baked in .NET stuff.

Thanks for the heads up about the long term plans. All the best for your migration :D

[peters]

Interesting - thanks for that insight. Why do you find the diffs become noisy? Do you commit the .po files to source control?

Unfortunately, yes 🎃

I'm currently using Loco, a translation management tool to manage the translations.

Aha! Interesting. I wish I had known about this tool earlier! But Azure Cognitive Services now provides you with human level translations for most languages we are interested in and they can also be manually corrected.

The thing I love about this repo's approach is that it handles everything at the request level, which makes it so much easier
than ASP.NET Core Localization to do things like localization of JS files and such.

Sure! It's very easy to get going if your business requirements allow you to serve assets using ASP.NET but once you require a CDN or people are frequently updating translations in a large codebase it's less fun! 💇‍♂️

No problem! Thank you! 👯

[ajbeaven]

Oh, sorry just another point. Am I right in saying that this repo doesn't currently support nugget tokens eg. [[[Hi, my name is %0|||John]]] or am I just doing something wrong?

[peters]

@ajbeaven It has probably been removed because our code does not use nugget tokens! :(