.NET native vs. custom localization
-
Probably a philosophical question, yet what are the reasons to create your own custom localization infrastructure instead of .NET native localization through resx and satellite assemblies? E.g. ABP framework for web apps includes its own localization engine which boils down to logical method Localize(key, resource), i.e. same logic as native. My rationale is that an app these days is a bunch of libraries (most commonly .NET standard). A GUI (ASP, winforms, WPF etc.) is just a (graphical) view of the app behind it with little to no business logic/entities. If the app libraries are properly localized, GUI has very little localization left. Each part of an app, is a library, which makes it conveniently localizable using .NET built in mechanism. There should be a good reason not to use it and I see none. Substitution of localization by DI is highly unlikely as that would mean somebody knowing more about app logic and entities than the app itself. It seams unlikely that one could get a significant performance improvement (worth building/supporting infrastructure) as well. Frequency of localization resources changes without respective changes in the app is very low. Therefore no need for "hot install" as well. To sum it up, KISS tends to be on native side.
-
Probably a philosophical question, yet what are the reasons to create your own custom localization infrastructure instead of .NET native localization through resx and satellite assemblies? E.g. ABP framework for web apps includes its own localization engine which boils down to logical method Localize(key, resource), i.e. same logic as native. My rationale is that an app these days is a bunch of libraries (most commonly .NET standard). A GUI (ASP, winforms, WPF etc.) is just a (graphical) view of the app behind it with little to no business logic/entities. If the app libraries are properly localized, GUI has very little localization left. Each part of an app, is a library, which makes it conveniently localizable using .NET built in mechanism. There should be a good reason not to use it and I see none. Substitution of localization by DI is highly unlikely as that would mean somebody knowing more about app logic and entities than the app itself. It seams unlikely that one could get a significant performance improvement (worth building/supporting infrastructure) as well. Frequency of localization resources changes without respective changes in the app is very low. Therefore no need for "hot install" as well. To sum it up, KISS tends to be on native side.
It's re-inventing the wheel when you haven't discovered what you already have (access to).
It was only in wine that he laid down no limit for himself, but he did not allow himself to be confused by it. ― Confucian Analects: Rules of Confucius about his food
-
Probably a philosophical question, yet what are the reasons to create your own custom localization infrastructure instead of .NET native localization through resx and satellite assemblies? E.g. ABP framework for web apps includes its own localization engine which boils down to logical method Localize(key, resource), i.e. same logic as native. My rationale is that an app these days is a bunch of libraries (most commonly .NET standard). A GUI (ASP, winforms, WPF etc.) is just a (graphical) view of the app behind it with little to no business logic/entities. If the app libraries are properly localized, GUI has very little localization left. Each part of an app, is a library, which makes it conveniently localizable using .NET built in mechanism. There should be a good reason not to use it and I see none. Substitution of localization by DI is highly unlikely as that would mean somebody knowing more about app logic and entities than the app itself. It seams unlikely that one could get a significant performance improvement (worth building/supporting infrastructure) as well. Frequency of localization resources changes without respective changes in the app is very low. Therefore no need for "hot install" as well. To sum it up, KISS tends to be on native side.
DI injecting is not that hard to build on top of for example resx - but indeed - is it worth it? There is no single answer to that. I would for example be tempted to use it for supporting pseudo-translation tests directly in the app without having to go through the localization tools to get the pseudo-translated resources for a quick I18N test. If I have translations with the UI or not depends on a lot of things - for example, if it is a WinForm application (not that I do those anymore) then the size of the controls is typically in the resource file along with the translation - typically making it more of a view thing than entity/business logic. Even in WPF/HTML the layout can effect the chosen translation (i.e. a less accurate but more concise translation being chosen for a label). In reality I think you always end up with plenty of strings throughout the layers. I understand both the translation and programming workflows, which makes it a bit easier for me to know when to customize and when to stick to standards. If you do not understand the translation workflow, stick to standards. Your little "optimization" could end up being rather problematic. This is less of a problem if you do not use professional translators with access to proper tools though (they won't know when you are wasting their time) :)