Sorry, but these are all tangents to this topic.
Is there anyone actually opposed to the MVP having localisation built in? I very much doubt so.
In that case can we progress to the discussion of which system to use. Which I can’t help with as I know very little about the .net ecosystem.
I’m also not versed on .NET but reading about it I found the following.
From .NET documentation, the steps needed to design an international app from the start:
Developing a world-ready application, including an application that can be localized into one or more languages, involves three steps: globalization, localizability review, and localization.
Globalization: the first stage of creating a world-ready application, which involves designing and coding an application that is culture-neutral and language-neutral.
Localizability review: the second stage of creating a localized application, which involves identifying potential roadblocks to localization.
Localization: the final stage of creating a localized application, which involves customizing an application’s user interface for specific regions or cultures.
Following those 3 steps have the advantage that (my emphasis)
It frees you from having to retrofit an application that is designed to support a single culture, such as U.S. English, to support additional cultures.
Pity that’s almost 10 years old and the question is closed but this SE’s Software Engineering offers interesting insights: Effective Strategies for Localization in .NET. The accepted answer focuses on Asp.NET web apps.
Asp.NET documentation is here: https://docs.microsoft.com/en-us/aspnet/core/fundamentals/localization?view=aspnetcore-3.1
My opinion is to bake in localisation from the start.
My opinion is also that English is fast becoming the global language that the French wanted their language to be… but the users of a site determine what the most useful language is. Most sites should be in English, as that is the most commonly spoken first or second language.
There may be a call for a Q&A site where most of the users can be expected to understand, for example, Klingon or Esperanto, but otherwise not have any other reasonably common second language, so we should accommodate speakers of different languages from the start.
Reading the comments here I am not sure if people understand the additional effort necessary for i18n. It is not just replacing hard coded strings with some strings fetched from a DB, or some templates. This is just the tip of the iceberg. Proper i18n will increase development time at around 30%.
Well we’re more talking about l10n than i18n here, and for asp it’s literally just taking an xml, translating the strings in there and then adding a 2 letter code to the file ending.
At least if you would be doing it “proper” anyway.
Obviously hardcoding strings in the code would make you a bit faster in the beginning.
My understanding is that localisation requires internationalisation.
for asp it’s literally just taking an xml, translating the strings in there and then adding a 2 letter code to the file ending.
That is the tip of the iceberg. Even if you start with hardcoded strings this is the easiest one to fix. Every decent IDE has an “Extract Strings” refactoring build in.
The harder stuff is:
And if you want to become mad there is still Russian and Turkish. There you have stuff like:
“XYZ” != uppercase(“xyz”)
If you managed to somehow survive the above hell, you could try to cope with font rendering issues for all those Asian languages.
By the way, with a 2 letter code you can not localize software, you only can translate it. For proper localisation you would need something like fr_CH.
I don’t think anybody here was thinking of having a French translation next to a Swiss French translation.
I have worked on localized c# applications for about eight years of my career.
I have no strong opinion on if the “later” version of the product should support alternate environment/language/regional variants in the conceptual sense, but I think that some people are significantly underestimating the effort involved in doing it remotely correct outside of western Europe and the Americas @tobltobs is correct that those items are harder than string resources, but after all of those you deal with issues like non-Gregorian calendars, round-trip safe vs unsafe conversions, format strings (when to use them, when to strip them and when to convert them) character length vs display length, how different browser/OS combinations report region and language differently etc. etc. etc. Then you get into the properly annoying stuff like petwebsite.com/tag/dog might translate to petwebsite.com/tag/chien but if you are talking about your chien having puppies you are talking about a chienne if you use simple resource substitution from a technical translation and the user then selects English all of your female dogs having puppies content just got firewalled in schools. Is this avoidable? Yes, does the average developer think about it before francophone devs or admins start “fixing” the translations? in my experience, no. Just like Auto Trader didn’t catch that they were advertising cars as having electrified handle doors and heated screen doors rather than power locks and windshield defrost for the first 18 months they advertised new GM vehicles in Spanish.
I spent 4 years working on c# asp.net products where the customers’ admin pages were statically invariant culture, but the pages for their clients were localizable in resources. The difference in dev and qa time was 2x or 3x for the pages that required localization even when the actual logic was 2-4 times simpler in the localized versions. That is not including the delays in getting QA staff fluent in those languages and regional issues or finding technical translators in the appropriate tongue, or the re-work once we actually tried a new culture with a native audience.
If localization will definitely be used enough to justify the cost/time, then putting it in up front, from the beginning and testing it as you go is the only way to really get it right without starting over in a lot of places, but the cost of doing it in the first place is significant. Doing it and not testing in anything other than invariant English is the same as not doing it as you will not catch any of the gotcha points where the framework’s toolchain lets you down or misleads you. It is a significant investment, much more complex than just a framework to allow translation of words, and even some pretty big players make the choice to just redirect users to a purpose-built site when they change out of the default language because it is a better result for the end user.
I don’t see the need to implement things like non-Gregorian calendars or similar in the MVP; just using ISO dates consistently should be fine.
Not even the capitalization should be needed; indeed, I don’t think it will be needed ever, there’s no need to have any automatic uppercase/lowercase conversion in the interface; if we really want to have some strings appear uppercase in some context and lowercase in others (not that I see any reason to do so), we can just have two strings, one in uppercase and one in lowercase. And I would advice strongly against automatically changing the case of any user-supplied content, ever (note that e.g. in German, sometimes changing capitalization can change the meaning!).
Even number-formatting is not critical (although I would be surprised if there were no ready-made functions for that). Displayed numbers numbers will likely all be not-too-large integers, where simply using the digit string without any additional formatting is sufficient.
th capitalization and calendar issues usually come up most as defects when you are comparing data from the client to data in the server. you can avoid much of it, but you still need to decide going in if you are going to allow things like partial string comparisons are meant to be equal and if/how you compare browser time to server time in cases where you cross a problematic conversion. ISO dates work fine as long as you never use the system date/time selectors for example.
These are all things worth deciding up front and testing for throughout if you chose to go outside of invariant server-side values.
I don’t think making the search dependent on the interface localisation is a good idea.
However I now got the idea that the search could be customised for the individual community (e.g. a search for a possible site about the German language would handle German umlauts in the right way). But that would be an issue local to the search functionality, and in particular would be necessarily independent of localisation. For example, a customised search for a mathematics community might handle the different ways a multiplication can be written (so that e.g. in searches a*b also matches a·b and a×b, and possibly even a.b — the latter is something you definitely would not want when searching in a programming community).
However such a customized search would clearly be non-MVP, and I don’t think you need to specially prepare for it in MVP either, as it would just be a modification of the search routine.
While that is true, I still have a very hard time imagining professional development without descent English skills. Take documentation for instance. I assume some of it is translated, but hardly everything. Everyday, I read English documentation for various functions in different languages, and I’m not a native English speaker, and we do not speak English at work.
I would say that the core problem here is governments who does not realize the value of teaching students English. But that’s not a problem Codidact or any other forum could solve.
I agree 
. I believe you have addressed the relevant point and have a (the?!) sensible solution. Systems Union provided (proprietary) accounting software and offered numerous language versions. However, if none of these languages suited the admin could adapt to any language whatsoever. All the text content (not such a huge amount, it was accounting software) was in ‘open’ tables with an optional ‘alternative’ field whose use would be preferred, when populated by whatever the admin chose.