I have several applications for several purposes in my company. Now that we need to translate to Japanese we need to provide a way to store translations.
Provide a central service to every application/team to add and get translations is a good idea?
How can I integrate this in my ASP.NET applications?
Thanks.
Here's the way I did this for a combination of web (MVC and WCF) and desktop (WinForms and WPF) apps.
A database repository of common strings was built that contained common words and phrases like Cancel, Save, etc. as well as business specific terms. Along with the DB a dev team utility app that would build a base localization library project. Individual app teams could then inherit this base and expand upon it for their specific needs. The idea was to provide the base while allowing customization to avoid delaying a project that needed new phrases added.
Within the individual apps, the strings were replaced by calls to the library. For example,
CancelButtton.Text = LibName.GetPhrase("Cancel"). The current CultureInfo was used to determine the user's language but this could be overriden for testing. If the phrase wasn't in the DB, it would default to the supplied string.
We had some debate over using local files, such as RESX, vs. a database repository. The plan ended up being to start with a database first and add the capability local files if there was a performance issue or the need for unconnected operations.
You could always use localized strings in something like an XML structure and just extract the information from the XML file. Every language got it's own XML file.
For example (from Android Localization):
#string/info_string = "Information in English"
Another file
#string/info_string = "Informationen in deutscher Sprache"
In your program you simply get the information that info_string stores.
Related
Trying to understand how to use WF rule engine outside of a WWF application. I've only read a blog post on the topic. But I have certain doubts on the feasibility.
My application requirements are as follows:
Web-based UI for writing the rules, and storing them in db.
A windows service will download the rule. A rule execution engine will gather data it requires and execute the rule, and give a result as output.
The rule is simply a set of instructions which must act on a row of a table. The schema of the table is dynamic; however there is some metadata which tells the rule execution engine how to gather the necessary inputs from that row.
I know that rules are usually input using a rules editor; this is a windows form application. This usually generates a *.rules file. The WF rules engine, as per my knowledge, evaluates this file and does the execution of the rule.
The *.rules file is an xml representation of the rule.
Is there any api in the dotnet framework which generates this xml representation? And, can we build a web-based front end for inputting the rules?
Was wondering if there was an api kind of thingy and I came across the following:
http://code.msdn.microsoft.com/windowsdesktop/Creating-Rules-Using-the-23c5d561
It is an api like interface. However it consumes objects from the System.CodeDom namespace (usually various kinds of CodeExpression objects).
To go about using it you have to correctly represent the code expression objects in your front-end via some mechanism (by using xml or json). In the server, i.e. when you post the rule to the server, you have to create the necessary code expression correctly (via parsing) and feed those things to the api.
You need two types of code expression objects - one for evaluation of the rule condition, and the other for the stuff to execute when the rule passes or fails. (I only need stuff to execute when rule passes).
The sample provided there gives you an idea of how to use the api. The rest is something you'd have to build on.
A program source code is commonly represented in memory using an AST. All you'd have to design for is making your own implementation.
If you want to use Windows Workflow Foundation (WF), you must have WF XAML generated - not .rules or XML representation of that (whatever that is). Here is an example of a Workflow XAML file. There are basically three ways to generate this (starting with the least complex method)
By using the designer in Visual Studio
By generating a DynamicActivity-instance runtime and serializing it
By implementing your own generator
To answer your question: Yes - it's option #2. If your rules are very simple (if-then-else) and you don't anticipate them to increase in complexity in the future, option #3 may be a viable alternative as well.
I am working on an ASP.NET project that is relatively simple except for one requirement which requires custom questionnaires be attached to specific types of tasks. These questionnaires need to be customized regularly and no development, within the app itself, should be needed add questionnaires. The questionnaires currently do not require an editing tool and can be done by uploading a template, changing something in a DB, whatever. They can be stored in any format and the resulting output needs to be captured to be edited or viewed later.
The types of questions in the questionnaire could be:
Selections (select one from a list)
Input (text, integers, dates, etc)
Yes/No
The ability to display questions based on answers from other questions. For example if they answer yes to question X, display question Y else display question Z. Need to be able to apply data validation such as required fields, ranges, etc on questions (could all be probably capture by basic regex).
The simplest break down would be:
Create a new event.
Based on the type of event display a specific questionnaire.
Questionnaires can change over time but they can be considered as new version each time and data will always be related to a specific version and not need to be migrated to updated versions.
The questionnaire output (data elements and a final calculated value) must be captured.
XML output (or any other format) of data elements entered.
The optimal (unicorn) scenario would be to have a basic template in XML or something that a user can learn to create easily and it would be stored and versioned in a DB. When a user makes a new event, the app would fetch the appropriate template which would display the questionnaire to the user. The user would fill it out and the output would be posted as some type of output (again XML would be nice but not required). That output would be attached to the event. Done.
Are there any .NET compatible tools/libraries that I could leverage to accomplish this? InfoPath seems like a tool that might be of use but I have almost zero experience with it so I am not sure about its constraints / implementation and if it is just overkill. The solution needs to be contained within the ASP.NET application. An external editor tool for creating templates would be ok but the templates must be viewable and editable on the web with no constraints to the user.
Can anyone provide examples of this being done or hints on how you might have tackled this?
Since the application is relatively easy to create other than this one feature, I would rather not spend 80% of my time trying to implement the custom questionnaire functionality and spend more time on the problem the application is trying to solve.
Tech available: ASP.NET, Silverlight, SQL Server
I would suggest having a look at a dot net nuke implementation, I am sure there should be a lot of viable options (if not all free).
DotNetNuke
Have a look at the Forge to see free plugins
Consider evaluating SurveyMaster at CodePlex. It's licensed under Microsoft Public License (Ms-PL), and you can modify its source for your needs.
The question might sound weird, but I am planning to create a asp.net website, which when fully done, will ideally cater to all countries.
I am currently in the architecture phase.. and is there anything that I should keep in might when doing this?
like
saving all datetime fields in utc
using user's timezone to display all time related data
all labels in the website to be localizable
is there anything else??
thanks,
Chris
A few additional points:
Some languages read from Right to
Left (Hebrew for example), which
will affect your UI.
Make sure your datastore supports
unicode (NVARHCAR vs VARCHAR).
Provide an easy way for translators
to contribute content. Usually means
creating a Data Driven Resource
Provider.
Internationalization and Localization is a good place to start.
You should think about how the localization process will take place. I assume you are not a native speaker in all languages you want to use for your application.
There are several approachs on how to address this: For example, there are companies that specialize in localization, meaning you give them an excel sheet, or an xml file.
You should also think about, where do you want to have all these localizations. Do you only want them in your ASP.net application, meaning in only one place? Then the resource file will be your way to go, because they are easy to handle and easy to send to localization studios.
But if you want to use the localizations in more than one place, you need to store them in a web service or in a database. Keep in mind that using localizations across multiple plattforms (e.g. web site, administrative tools) will force you to write import/export functionality for the used tables. (Because you won't give the localization company access to your database)
I would start by looking here: http://msdn.microsoft.com/en-us/library/c6zyy3s9.aspx.
I also guess you are working on doing a SQL database. If that is the case look at things like using nvarchars.
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.
I'm using Visual Studio (2005 and up). I am looking into trying out making an application where the user can change language for all menues, input formats and such. How would I go on doing this, as I suppose that there is some complete feature within .Net that can help me with this?
I need to take the following into account (and fill me in if I miss some obvious stuff)
Strings (menues, texts)
Input data (parsing floats, dates, etc..)
Should be easy to add support for another language
I'm not an expert with .NET by any means but Localization is never just as simple as "swapping out String values" or "changing date formats". There is much more to be taken into consideration such as layout, proper text placement.
Take Chinese for example. The way you read is top to bottom not left to right. If properly localized the app should take that into account.
http://msdn.microsoft.com/en-us/library/y99d1cd3(VS.80).aspx seems to be a good start though if you're dealing with Windows Forms.
The classic recipe is: design the app with no native language but a localization facility, and develop an initialization into one language (e.g., English). So you build the app and localize it into English every night; without the localization step it would not be usable. Do that well, and the resources for the initial sample localization can be replaced with those for any other language. Take into account non-roman scripts from the beginning. It's much cleaner to have a no-language app that always requires localization rather than a language-specific app that needs to have its native language subtracted and a replacement added.
For strings you should just separate your strings from your code (having an XML/DLL that will transform string IDs to real strings is one way to go). However you do need to make sure that you are supporting double byte characters for some languages (this is relevant if you use C/C++).
For input data what you want is to have different locale's. In Java this is relatively easy, and if you use C# it probably is quite easy also. In C/C++ I don't really know. The basic idea is that the input parsers should be different based on the locale selected at that time. So each field (textfield, textbox, etc.) must have an abstract parser that is then implemented by a different class depending on the locale (right to left, double byte, etc.).
Check the Java implementation for details on how they did it. It is quite functional.
You definitely need to be using the .NET ResourceManager and the resx file xml format, however there are a number of approaches to using this.
It really depends on what you are wanting to achieve. For me I wanted a single xml resource file (for each supported language) that could be modified by anyone. I created a helper class that loaded the global resource file into ResourceManager (once only) and I had a helper function that gives me the required resource for a given name. The only disadvantage in this approach was that I could not leverage dynamic binding of resources to properties.
I found this better and easier to manage than multiple or embedded resource files for every form. Additionally exactly the same approach can used in an ASP.NET application. I also found this approach means that outsourcing translation of resources and shipping language packs to customers much more manageable.
Microsoft's recommended approach is to use satellite assemblies, as described in Packaging and Deploying Resources. If you're using a ResourceManager to load resources, .NET will load the correct resources for the CurrentUICulture. This defaults to the user's current UI language setting in Windows.
It is possible to localize Windows Forms either through Visual Studio or an external tool, WinRes.exe. This article describes WinRes and how to use Visual Studio to localize the form.