I have read many articles and questions here on SO about this, however I am still not comfortable. I am planning to develop a plug-in based GUI desktop application based on MEF technology.
I would like to provide a localization support for the application. The problem is that even if I localize the host application, the third party plugins which are basically DLL files and can be installed any time, will also need to be localized.
I think having all localizable controls in a dll is not an option for me. I can store the international texts in a database, have a caller function which is retrieving the text from DB in the host applciation, and ask plugins to call this caller function. Or I can ask the developers to have different resource files in their applications, but this way, they will not benefit from already translated texts.
What is the best practise to provide multilingual interface for this case?
I'm not sure that there is one best practice that applies, but I can talk you through the options as I see them. If you develop a central database with your different translations for everything, all of your tools can benefit from the translations. However, the downside is that now all of your plugins will also need to know about the database (in some way). That adds a more direct coupling that I prefer to avoid when using third party plugins.
If you use the resource files, you gain more flexibility but lose the ability to reuse the same text (which feels like you are violating DRY).
Personally, I would go down the resource file route for your localization. It provides you the simplest way to get everyone working without major dependancies. However, if you can figure out a way to have the plugins call the central application for their localization text, the central database would be a better option (again, in my mind).
Here are a couple links that might help you out as well:
Is there a best-practice approach for internationalization of an application?
http://www.businessandprocess.com/2010/11/why-application-localization-should-start-in-the-design-stage/
http://expatsoftware.com/articles/2010/03/why-internationalization-is-hopelessly.html
Related
I have three programs (one in C++ + WinAPI, another one in C# .NET and the last one in Java) with different functions. I am about to choose one and implement functions of the other two. Is it possible to somehow merge them? I need to have them in one GUI, under one process (at least visually). IPC isn't a problem.
Thanks for anything
I think the best/easiest thing you could do is make the GUI only in C#, in windows clients you could use Windows Forms or WPF, in web based you can use ASP.NET WebForms or ASP.NET MVC.
in all these cases except MVC (Razor) you have really good tools for designing and customizing the GUI within Visual Studio.
Your C++ code can be wrapped in a class library or as you say accessed via some kind of IPC if it has to run as application, same for Java but if you are 100% free to write and re-write things you could also imagine to port the Java code to C++, this could be easy, difficult or impossible depending on what the java code does.
at last resort if both C++ and Java applications must stay separated and must run in background on same or another machine and you still want to consume their services or methods from your C# GUI, as you mentioned, IPC is probably the way, not sure what you can do in Windows with Java and IPC, surely java can expose or consume XML web services.
The problem you will find is that each has its own process model, and you either need to get the process models to coexist or you'll need several communicating processes (though the user need not see them). With Java, eg, it can be "king", or you can set up a sort of sub-process in another process, or you can have it set up/take down its process model on every call. Which approach is best depends in part on the complexity of the operations you'll be doing in the "guest" language.
The one main thing, though, is that only one language can control the UI -- in general different language UIs don't coexist, and I doubt that you can have eg, a Java UI object in a C# GUI, at least not without treating it as a foreign window.
If you're talking about the best language to rewrite the programs in, that depends entirely on the primary function. If you mainly need it to integrate with Windows nicely, C# would be the obvious choice. If your main idea is to make it cross-platform, it'd make most sense in Java.
If you're talking about running them together and using IPC then yes, that's possible too - you could use anything from a fully blown IPC framework to a custom protocol over sockets on localhost. There shouldn't be too much of an issue there, though remember depending on how big the parts in other languages are, it may cost just as much in terms of time to rewrite them (and there's less of a maintenance burden that way too.) There's also complexities with controlling GUIs from other processes, it can be done ish by passing native canvas IDs around cross process, but it's hard to get working properly, may not be particularly safe and makes it quite difficult to work out what's going on from a maintenance perspective.
I am looking for the best solution to make it easy to add new languages to an asp.net website without deploying/building the existing code base.
From what I have researched, it seems that you can compile resource files on the fly into Satellite assemblies but I am uncertain how to make the application use these DLL's once generated?
The other option I have seen is to store the translations in the Database, and write a custom ResourceProvider so that the built-in localization methods can be used, whilst abstracting the actual implementation (in this case a database).
Either way, the front end for this site will be the same (meta:resourcekey for the controls etc).
But I am struggling on deciding which approach will be the easiest to upkeep. For example, does publishing a new Satellite Assembly restart the Application Pool or does everything tick over nicely?
EDIT
The translations will be provided by a 3rd party API so human maintenance quality is not important. I thought I would add this due to the answers received.
With Asp.Net (currently) you do not have to compile by your own, you can simply deploy resx files (to App_LocalResources or App_GlobalResources folder) and Asp.Net will take care of compiling them into Satellite Assemblies. That's cool.
With Database approach, you are risking the problems with synchronization: how will you know if given resource string is translated? Also, correcting them is not very easy (for Translators/Localization Engineers). And you would need to prepare "install" script anyway. If that is what you are going to give to translators, good luck. You would face plenty of overtranslations and you would have to correct them (manually?).
Resx files (being simple XML) are a bit easier to validate (it is either valid XML in terms of given XSD or it is not). Besides, it is standard technology, you won't need to implement anything by yourself. That is why, I would recommend it.
EDIT
Another issue with Database-driven resources could be character encoding. You would need to create your own translation kit. My experience is, the result might be in several different encodings. Especially, if you want to use plain text file. On the other hand, default encoding of XML files is UTF-8...
RESX
Having around 30+ languages in mit Windows Forms and Web Forms application (this one, if I'm allowed to place a link), I finally had most success with simple RESX files in App_LocalResources.
What I discovered though was that the compilation was extremly slow in VS.NET, so did a slightly modified approach:
Have only English RESX files in the VS.NET solution.
Have a shadow structure of the website with only the App_LocalResources for all languages, including English in a separate folder, not visible to VS.NET.
Write a simple CMD script to copy the real English resources to the separate folder.
Use my free tool Zeta Resource Editor to actually translate inside the separate folder.
Have a publish script that copies the real web files (like ASPX, ASAX, MASTER, etc.) to the website and also copy the resources to the websites.
This approach makes compilation really fast and still allows me to keep compilation and translations separated.
The drawback is that the first call of the live web application compiles rather long, until now, I figures no way to speed this up/precompile (although I do believe that this is possible).
Database
I also did some projects with localization in database and custom <%#...%> blocks to load the languages.
Today, I would vote against this as it is non-standard. Although it would be probably just as fast to compile, no matter whether 1 or 50 languages are involved.
3rd Party Tools
You also could fetch a commercial product to do the translation, if I could afford, I would have done this most likely, too.
Just my two cent...
Is there any resources that how to create windows application, especially for how to design the dll to wrap up the api calls or the similar?
It seems that people don't compile the entire project into a single exe for release and what is the best practice to architect the windows application component based on MVC pattern?
Is the dll used for share the common api between different application (.exe file) ?
Is there any resources or any good book on this topic?
I appreciate if anyone can shed some light on.
You can read general overviews on dynamic link libraries (DLLs) on MSDN or Wikipedia or numerous other sites on the web. Some important uses/benefits of dynamic libraries include:
Sharing common functionality between different applications/modules without duplicating the code
Exposing APIs to other applications or programmers through a programmatic interface
Breaking an application's code into smaller chunks for possible load-time/run-time performance gain (e.g. lazily loading infrequently used modules)
Increasing granularity of application patches / service packs, etc.
Providing a late-binding mechanism for conecting an application with the APIs that it uses, improving potential for cross-version compatibility and separate implementations of an API set
The best approach for factoring an application's binary modules varies widely, depending on the specific situation. Sometimes you can start by placing all code of an application in the same binary and, over time, identifying commonly useful bits and moving them out into DLLs. In other situations, it may be more clearly apparent up front how to slice and dice your application into a handful of libraries.
Is it ok to roll your own localization framework? I would be ok using the default .NET localization behavior (i.e., putting text in resource files named a certain way in the assembly), except that we have localized images and text that need to be rendered in DirectX in addition to WinForms and WPF.
I could put form-specific strings in one place and other strings somewhere else, but I think that it makes more sense to keep everything in one place, not to mention it will help to avoid duplicates (for domain values like Yes/No, etc.). It's also possible we may be moving this tool to another platform in the future, so it would be nice to have all the localization information in one platform-agnostic area.
I realize this is a little subjective, but I'm looking for a best practice here...I've worked on projects that take both approaches. Any thoughts?
I have developed systems in which localisation is implemented via database-stored data and metadata. If your app is already making intense use of a fast database backend, you could create a database-backed localisation layer and use it to store localised information, including textual and non-textual data. It has worked great for us in a few ocasions.
Edit. The details won't fit in here, but basically we mirrored the logic of the key/value resource manager that the Windows API or .NET use. We extended that by allowing resources to be grouped into groups, which can be nested arbitrarily. Resource names can be given as, for example, "ClientManagement.MainForm.StatusBar.ReadyMsg", meaning the ready message text to display on the status bar of the main form in the client management user interface. On app startup, a locale setting is read from a config file and a resource manager initialised with it; all the subsequent calls to the resource manager will be using such a locale setting until explicitly changed. We also built an administrative user interface that allowed us to edit the resources stored in the database, and even add new languages. A final comment: data to be localised is not only labels and icons on screen. Option values in combo boxes, for example, also need to be localised.
We implemented a localization using DB backend. We were able to create a great resource editor which allows "translator" end users to dynamically update translations (cannot do that with a resx!). We were also able to support an approval process and group translations by module such that an entire module could be approved for use in a language, or not.
We also decided to implement the localization provider for Asp.Net, which basically does 'automatic' localization with no code by the developer. This was actually the only difficult part of the project as the interface is not well documented. It was hard to debug because it actually runs within Visual Studio host process. We used a web service to decouple the implementation which greatly simplified things. Another good thing is that the translations are automatically cached so the DB is not working as hard. A bad thing is that when your translation service/back end is down and if you do not precompile your asp.net web site, when the user launches a 'new' page, the compiler might decided NOT to translate the page. This behaviour remains (even after the translation service starts up again) until you force a recompile of the site.
Are there any resources with information creating a self contained, reusable module?
I need to create modules that I can drop into projects quickly and easily. An example would be a news module that would contain an admin area, news listing page, It supporting CSS & JavaScript, etc.
Am I smoking my socks or is this even possible?
You need plugins for your application.
I've got a plugin library (in development and in Spanish) that you might use as an example or a starting point. I don't know how good google translate will be but you can check a C# plugin tutorial in http://translate.google.com/translate?hl=es&ie=UTF-8&u=http://www.thealphasite.org/es/sistema_de_plugins_con_c_y_net&sl=es&tl=en
A plugin allows you to plug in :P functionality into your application and, with a proper design, it will allow you to move functionality dinamically from one application to another.
Anyway, plugin just provide with ease of use but require a design specifically thought with them in mind. On the other hand, basic "take this module and use it in another project" is just proper encapsulation and good design. If a module is well designed the it should be able to be ported to another site or application with very little effort.
Keep in mind that, specifically for web, "theming" is a complex subject, that is, adapting your plugin to the way an specific web looks is another step of customization which has to be included into the module itself. You can see an example in the Drupal theming functions and the theming api documentation.
Look at www.allnewsmanager.net, maybe is what you are looking for. It is a reusable module, free and open source.
Not sure about any resources - but I've done this myself by writing a CMS from scratch using a combination of user controls for the modules, and a templating system with common code file which loads said user controls into placeholders.
The templating system allows you to create an aspx file, with a bunch of placeholders (as many as you need) - then you need a database or similar to manage what controls go to what placeholders, on what page. A template can handle many pages.
Downloading and studying the architecture for dotnetnuke can enlighten and give ideas for structuring your own approach, even though it's VB, the data structure is just as interesting.