Question:
This is a followup-question to these posts:
i18n performance: resx vs. database?
Are resx files suitable for Internationalization?
If I would use resx files for internationalization (localization), under this scenario:
ONE application (one source, one project, one executable) for all
customers
many customers
multiple languages per customer
customization of labels possible per language per customer
application gets replaced from time to time with new version
Is it possible with resx files to maintain customization of field labels ?
I mean for one customer and one language, it would certainly be possible.
But for N customers with N languages...
Wouldn't I be required to create N resx files for N customers and every string I add in one file, I must add to every resx files ?
Also I would have to take back resx files (as customization happens at the customer).
Is a resx file really suitable for this ?
To me it sounds like it is not (not at all), but on these two posts, people seem to perceive it as the best solution.
This appears doubtful to me.
To me it appears as if resx files just can't deliver the flexibility and maintainability required, and it also appears to me, that under a database-driven i18n, this would be comparatively easily implemented.
Does anybody who works with resx files have actual experience with this kind of scenario, or used and maintained their own product ?
In this case I would use XML files which the user can easily directly customize or from a form in the application.
Related
I have a web forms ASP.NET application; I'm trying to automatically generate a list of which pages speak to which SQL tables, as our DBM is going to attempt a database rewrite and needs to know which pages will be impacted by each change. This is a... very poorly written application that I've inherited, it's only used internally by a couple dozen employees. There is little proper documentation, which I'm trying to fix.
I have text files of all tables/views/stored procedures in our database, which I intend to load into lists to be referenced. What I'm hoping to do is write a small function (preferably in C# but powershell or other methods will work too) that will iterate through every .aspx and .cs file in our wwwroot directory (including those within subfolders), searching for any occurrences of the names in the reference lists. If it finds a match it should note which file and which table(s), then continue.
I don't know how to most efficiently search through the contents of these files, and I'm barely an intermediate coder so my knowledge of what is or isn't possible is quite lacking. For all I know there's a much simpler way to show which pages speak to which tables, but I'm not sure.
Agent Ransack may be your best bet for searching through files/directories.
http://download.cnet.com/Agent-Ransack/3000-2072_4-10043846.html
Does anyone have any idea of the pros and cons of using resx vs json files for some enums (that will be possible values for attributes)?
I'm not sure what to use. And to use a database system for this would be overkill, as I'm just talking about a few lists of enums.
Small update
At the moment , the only difference I can see is that with JSON storage I'm not limited to changing those lists at compile time, but they are not going to change very much over time so that is a negligible factor.
Resx file is good if you want some capabilities of localization, like to store your enums in different languages and so on. Json format is much more flexible and it is not depend on the .Net environment.
From this link
Resource files give you an easy way to localize/internationalize your
.net applications by automatically determining which language resx
file to use based on the user's locale. To add more languages, simply
add another translated resource file.
Resource files give you a
central location to store your strings, files and scripts and refer to
them in a strongly-typed manner (so the compile will break if you
reference them improperly).
Resource files can be compiled into
satellite assemblies, making it easy to change up the resources in a
production application without having to recompile the whole thing.
I am about to start a localization project for my employer. It concerns a pre-existing project with many windows forms and an established code base, programmed in C# and ASP.NET. I have done research into how to localize an application in visual studio and found resources.
While these are an adequate solution to the problem, I am not entirely happy with the down sides of using resources. This is to say, it has a rather large footprint, requiring changes in each of the form files. Furthermore, the resource files are only editable from within Visual Studio. I would prefer enabling external translators without programming knowledge to do the translation.
So I came up with an alternative solution:
Build a static localization utility class with an extension method on String:
public static String Localize(this String s)
The utility class loads localization strings from file on startup. When the program needs a string somewhere, it is called as
"foo".Localize();
And the program would use the string itself as the key in the table to find the translation.
It seems a safe and effective solution, and I'm happy with the small footprint that it leaves on the existing codebase.
Basically I want to ask:
Are there downsides to my solution that I've missed?
Which file formats for the localization data should I look into (I've already encountered the .po file format)?
Is it a good enough reason to deviate from the resource files solution?
Any advice and/or considerations you may have will be appreciated.
You are trying to reinvent the wheel that MS invented long ago. You can use plenty of tools available for resources or even write your own Resources provider.
Some tools available: What tools are available for adding Localization to an ASP.NET project?
If you want to use a database for translators: Data Driven Resource provider from Rick Strahl
Are there downsides to my solution that I've missed?
I can point out some, what about the texts in the aspx files. Are you going to make your extension method available to them as well? That would be tough I guess.
e.g. <asp:Label Text="Title"> - how are you going to translate that?
Further, some of your claims are not entirely true.
the resource files are only editable from within Visual Studio
They are xml files , so you can use any editor to edit them or write a custom utility to do that.
Are there downsides to my solution that I've missed?
The standard resource files go beyond changing the text.
You might need to resize certain elements to fit the new text (if you don't use the existing layout management mechanism). And for some languages you will need to change the fonts/fonts sizes (think Chinese, Japanese, Korean) or alignment (think right-to-left languages like Arabic and Hebrew).
Also, translating standard files means that using an editor that is aware of the format one can see the dialog "as is", so it gives more context than stand-alone strings, which results in better translation quality.
We have a program that is used in one specific industry and has strings that are specific to that industry. We now have the situation where it can be used in another industry and we want to customise the strings for that industry without duplicating our code base.
The problem space appears very similar to localisation. Are we going to have a separate resource assembly for each industry? If so when would we choose which assembly to use, could we do this at install time or would it need to be at compile time?. How do we keep the separate resource assemblies synchronised, so that the same keys to messages appear in each one?
What is the best way to do this?
Let me re-phrase it: you have an industrial application which could be used in various industries and the only things that are different are resources (that is strings, layout, maybe images and sounds). The other code stays the same.
In such case your problem is not just similar it is actually identical to Localization. And as such you can use Satellite Assemblies.
Now, it is up to you if you want to package such created applications separately or distribute one application with both problem spaces.
The first seem more realistic scenario to me - you would need to decide on which .resx file to include at compile time (i.e. during project preparation you would overwrite existing resources with problem-space resources and then proceed with compilation, that should give you different flavors of your application; I would also modify their names in such case).
The latter would require you to manually instantiate ResourceManager at runtime to read from valid satellite assembly - it could be based on some configuration file. It means more work (you would need to actually modify your code) and you will end up distributing both flavors of your application at once, that is you won't have control over how your customers will use it. From the business perspective it could be a little dangerous.
EDIT (Note to self: read whole question carefully)
Somehow I managed to miss install time vs. compile time. I believe compile time is the answer because of the same reason I gave in config-driven switch section: you would package the resources and you won't have any control on how customers use it. Some clever guy would figure it out, that is for sure.
I would recommend having a properties file with key value pairs. Where you currently have industry specific strings, replace them with calls to the properties file. Obviously you would cache these strings in some container. I don't know the C# container - Java would use java.util.Properties.
aerospace.props:
INDUSTRY_NAME=aerospace
INDUSTRY_START_YEAR=1903
manufacturing.props:
INDUSTRY_NAME=manufacturing
INDUSTRY_START_YEAR=1600
We're maintaining a web product that we've sold to several different customers. We support the site in native and english. As a part of the maintainence we've begun updating to .NET 3.5 and while during this we would like to have better support for differentiated layout/localization in the product.
We're trying not to have any customer logic containing inside the code. For example, we try to avoid code like this:
if (config.Customer = customer1)
SetupPageForCustomer1();
else
SetupPageForCustomer2();
Instead we try to put all customer differentiation in config files so we can have the much cleaner code:
SetupPageForCustomer(customer1)
void SetupPageForCustomer(Customer c)
{
PageConfig pc = LoadPageConfig("config/" + c.Dir + "ThisPage.aspx.config");
SetupPage(pc);
}
We've handled the layout differentiation by letting the pages that needs differentiation have a usercontrol for each customer that is loading dynamical on page_load. Localization is currently being handled with resource files which works great. Since we support two languages each page comes with two resource files. If we need to differentiate the text on these pages for customers, however, we will end up with (number of languages * number of customers) resource files which seemes to be a lot of maintainence work.
What are your views upon this issue? What is the best way to handle these kind of things?
Perhaps you can split the localisation into two files. One file for the general content in the target language and then a file for the customer in that language. So assume you are going to a German translation you would have one file that was generic for all German customers and a file for each German customer. This is still a proliferation of files but would mean that each of the files wold be smaller and more specific.
This is a bit of a hack, but if you really need different text for different customers, it might be one of the more clean ways to do it:
From .NET 2.0 and on, you can create new cultures. (See How to: Create Custom Cultures.) I would suggest creating a new "culture" from your configuration file, inheriting from the culture representing the language in use. Once you have a new culture, you can create a resource file for just the strings specific to that customer, having it falling back on the defaults if no override is given.
Edit: Also, here's an article describing how to use culture for customer specific language use: .NET Internationalization: Using Custom Cultures
I cannot tell how your LoadPageConfig works.
Some ideas:
If you want to have as little files per customer, you could load your resource files dynamically (at run time) so you would not need to create extra cultures.
for real configuration differences, consider loading a single configuration file per customer with customer specific settings, as described in this article. The same approach can be used in ASP.NET.