I am trying to come up with a way to automate testing of localized UI in ASP.NET WebForms. Basically I have button that toggles the current locale and code that populates the right text from resource file. The problem is how to test it.
One approach is to use BDD in a form of
As a Spanish speaking user
I want to switch to Spanish
So that I can use the site more comfortably
Scenario Outline:
... a bunch of steps to get each possible string (labels, buttons, messages, etc)
Another approach is to use TDD in a form of row based tests and check each property (which is WebForms is not trivial).
The first approach forces repeating existing scenarios, the second is very difficult and not clear.
How do people test localization?
Well I am in the same boat at this moment...
What I am trying to do.. is
to extract the user-visible strings used by the automated tests out into a swappable block (in my case this is a .net resource file). The idea is to have different machines (or VMs or change at runtime) and run the same suite across different localized versions of the app.
That leaves the switch language feature (that we don't support at the moment): that you could test by exercising the switch behavior and doing a cursory check in a test.
Finally you really need a set of human eyes to ensure everything has been localized and is accessible (e.g. not clipped and stuff). There are other aspects too that can't be automated.. e.g. the use of colors to signal alarms.
To ensure there are no hard coded user-visible strings, create a junk resource file with junk characters, wire it to the app and manually breeze through all the screens periodically (every 2 weeks). If you still see english strings, something still resides out of the resource file. Once everything is in the resource file, you still need someone who speaks the language to ensure that the localized strings appear correctly or match the context in which they are shown.
Related
I have an application in ASP.Net in AngularJS, until then that my application had the need only in Brazil, but recently the company where I work needs to make this site available to other countries in other languages like Spanish and English.
I have never worked with International applications, so there will be many doubts and difficulties.
I'll start with the difficulties:
- My application has fixed texts in the html, database and code, how can I translate all these fronts? Is there a component that translates everything into the client? (Javascript, AngularJS, etc ...).
- Development time for this change (Too much code to change).
Questions: - Decimal, Date and Time, how to work with these values in an International application? (My application has many logs and values to display and insert)
I'm researching a lot but really needed a hint of where I could go.
Thank you, I'll wait!
I would start searching for "Localization". There is something called "AspNetBoilerplate" that has implemented localization into there project. Here is their link: https://aspnetboilerplate.com/ and here is document on how to use it within their project: https://aspnetboilerplate.com/Pages/Documents/Localization. You can easily download a free project and see what they did to implement it.
They have different localization files based on language being used. The language being used is a setting in the DB based upon the tenant that logs in. All static text looks up to its respective localization file (See their .Core project under "Localization" to see all their files).
As far as DateTimes/Decimals/etc, I would have extension methods that looked up the cached localization being used and format respectively.
By no means am I recommending you use this software but rather see how they implemented it within their project. Also, know that I have only had to do this once and there may be numerous other ways to accomplish this goal.
This is more of an advise / best practice question that I'm hoping someone has come across before and can give me a steer.
I need to build a web application (the client would like webforms because that's what their developers know for when i hand it over)
Essentially when the client logs in, they will pick a language then I need to replace the text for menus, input boxes etc. The client wants to add their translations and update them at any time.
Ideas I have looked at are:
Holding the translations in resource files, building an editor in to the web application and then adding attributes on the fly to my viewmodels.
Holding the translations in sql server so i have the name, language and translation as a lookup e.g. Home | French | Maison. Then on pre-render I'll scrape the screen for any controls needing translation in the menu, labels, text areas.
Does anyone know of any good examples or had the experience of doing this themselves.
I've a similar situation, and chose to store data in SQL.
Translation mistakes happen often, and you don't want to recompile or disassemble every time.
It is possible to avoid the need to republish, but I've found it just more intuitive and straightforward to maintain SQL.
Bottom line, it depends on the amount of data you have. If it's more than just a couple of keywords, it sounds like a job for SQL to me.
Edit:
In a similar question, users recommend using resources, claiming it is the standard method.
However, if your users are going to make changes to values on regular basis (not because of mistake correction, but because data actually changes), then SQL seems best fit for the job.
We are going to develop an ASP.NET website in 30 language.
What is the best solution for developing that site? which architecture to be used?
I suggest storing UI properties in resource files (.resx) and have the CurrentUICulture to the specific language for each request:
<globalization culture="auto" uiCulture="auto" />
If your Web site is mostly content-oriented rather than a business oriented application that differs heavily based on the language, you might want to consider building separate set of pages for each language and redirect the user based on a cookie or profile property or Request.UserLanguages. It's not possible to give a general prescription for globalization problem. The best architecture differs significantly based on the nature of each individual project.
NLS is a recurring requirement, and often when the question about NLS functionality is asked, the people asking are not aware of the complexity. NLS typically split into (at least) 2 areas:
NLS in the UI
NLS in the data
In your case, a content-based website, you may even split the second point into - data generated by the website provider and - user generated data.
For UI NLS you can use the .resx mechanism as mentioned by Mehrdad, but you should be aware that every work on localization always requires to edit the source code (i.e. the resx files).
When I had to develop a multi-languge web app, I therefore chose to handle the NLS requirement in my code, and created a couple of NLS-specific tables that mirrored the UI (btw this was the motivation to write graspx: extract all visible texts from aspx source, such as Label.Text etc). There is a separate application to upload the UI definition, and let translators do their work. The main application has an import functionality for the translated texts.
The data model looks like this: Page - PageItems - PageItemTexts (with reference to a Language), so it's quite simple.
The same model can be applied to the content: instead of Page and PageItems, you simply have ContentItems, which hold a PK and a identifier only, and a table holding the text of the ContentItems associated with a language.
Additionally, you may define some sort of language fallback chain, so that a text which is not yet translated is displayed in the original language, or some other (closely related) language.
The displayed language can be selected by the language provided by the browser (HTTP_ACCEPT_LANGUAGE), but should be allowed to be overwritten by the user (e.g. via a combobox). The selected language should be stored in a session variable, in a cookie, or in the database (for registered users).
A client wants to "Web-enable" a spreadsheet calculation -- the user to specify the values of certain cells, then show them the resulting values in other cells.
(They do NOT want to show the user a "spreadsheet-like" interface. This is not a UI question.)
They have a huge spreadsheet with lots of calculations over many, many sheets. But, in the end, only two things matter -- (1) you put numbers in a couple cells on one sheet, and (2) you get corresponding numbers off a couple cells in another sheet. The rest of it is a black box.
I want to present a UI to the user to enter the numbers they want, then I'd like to programatically open the Excel file, set the numbers, tell it to re-calc, and read the result out.
Is this possible/advisable? Is there a commercial component that makes this easier? Are their pitfalls I'm not considering?
(I know I can use Office Automation to do this, but I know it's not recommended to do that server-side, since it tries to run in the context of a user, etc.)
A lot of people are saying I need to recreate the formulas in code. However, this would be staggeringly complex.
It is possible, but not advisable (and officially unsupported).
You can interact with Excel through COM or the .NET Primary Interop Assemblies, but this is meant to be a client-side process.
On the server side, no display or desktop is available and any unexpected dialog boxes (for example) will make your web app hang – your app will behave flaky.
Also, attaching an Excel process to each request isn't exactly a low-resource approach.
Working out the black box and re-implementing it in a proper programming language is clearly the better (as in "more reliable and faster") option.
Related reading: KB257757: Considerations for server-side Automation of Office
You definitely don't want to be using interop on the server side, it's bad enough using it as a kludge on the client side.
I can see two options:
Figure out the spreadsheet logic. This may benefit you in the long term by making the business logic a known quantity, and in the short term you may find that there are actually bugs in the spreadsheet (I have encountered tons of monster spreadsheets used for years that turn out to have simple bugs in them - everyone just assumed the answers must be right)
Evaluate SpreadSheetGear.NET, which is basically a replacement for interop that does it all without Excel (it replicates a huge chunk of Excel's non-visual logic and IO in .NET)
Although this is certainly possible using ASP.NET, it's very inadvisable. It's un-scalable and prone to concurrency errors.
Your best bet is to analyze the spreadsheet calculations and duplicate them. Now, granted, your business is not going to like the time it takes to do this, but it will (presumably) give them a more usable system.
Alternatively, you can simply serve up the spreadsheet to users from your website, in which case you do almost nothing.
Edit: If your stakeholders really insist on using Excel server-side, I suggest you take a good hard look at Excel Services as #John Saunders suggests. It may not get you everything you want, but it'll get you quite a bit, and should solve some of the issues you'll end up with trying to do it server-side with ASP.NET.
That's not to say that it's a panacea; your mileage will certainly vary. And Sharepoint isn't exactly cheap to buy or maintain. In fact, short-term costs could easily be dwarfed by long-term costs if you go the Sharepoint route--but it might the best option to fit a requirement.
I still suggest you push back in favor of coding all of your logic in a separate .NET module. That way you can use it both server-side and client-side. Excel can easily pass calculations to a COM object, and you can very easily publish your .NET library as COM objects. In the end, you'd have a much more maintainable and usable architecture.
Neglecting the discussion whether it makes sense to manipulate an excel sheet on the server-side, one way to perform this would probably look like adopting the
Microsoft.Office.Interop.Excel.dll
Using this library, you can tell Excel to open a Spreadsheet, change and read the contents from .NET. I have used the library in a WinForm application, and I guess that it can also be used from ASP.NET.
Still, consider the concurrency problems already mentioned... However, if the sheet is accessed unfrequently, why not...
The simplest way to do this might be to:
Upload the Excel workbook to Google Docs -- this is very clean, in my experience
Use the Google Spreadsheets Data API to update the data and return the numbers.
Here's a link to get you started on this, if you want to go that direction:
http://code.google.com/apis/spreadsheets/overview.html
Let me be more adamant than others have been: do not use Excel server-side. It is intended to be used as a desktop application, meaning it is not intended to be used from random different threads, possibly multiple threads at a time. You're better off writing your own spreadsheet than trying to use Excel (or any other Office desktop product) form a server.
This is one of the reasons that Excel Services exists. A quick search on MSDN turned up this link: http://blogs.msdn.com/excel/archive/category/11361.aspx. That's a category list, so contains a list of blog posts on the subject. See also Microsoft.Office.Excel.Server.WebServices Namespace.
It sounds like you're talking that the user has the spreadsheet open on their local system, and you want a web site to manipulate that local spreadsheet?
If that's the case, you can't really do that. Even Office automation won't help, unless you want to require them to upload the sheet to the server and download a new altered version.
What you can do is create a web service to do the calculations and add some vba or vsto code to the Excel sheet to talk to that service.
How should I store (and present) the text on a website intended for worldwide use, with several languages? The content is mostly in the form of 500+ word articles, although I will need to translate tiny snippets of text on each page too (such as "print this article" or "back to menu").
I know there are several CMS packages that handle multiple languages, but I have to integrate with our existing ASP systems too, so I am ignoring such solutions.
One concern I have is that Google should be able to find the pages, even for foreign users. I am less concerned about issues with processing dates and currencies.
I worry that, left to my own devices, I will invent a way of doing this which work, but eventually lead to disaster! I want to know what professional solutions you have actually used on real projects, not untried ideas! Thanks very much.
I looked at RESX files, but felt they were unsuitable for all but the most trivial translation solutions (I will elaborate if anyone wants to know).
Google will help me with translating the text, but not storing/presenting it.
Has anyone worked on a multi-language project that relied on their own code for presentation?
Any thoughts on serving up content in the following ways, and which is best?
http://www.website.com/text/view.asp?id=12345&lang=fr
http://www.website.com/text/12345/bonjour_mes_amis.htm
http://fr.website.com/text/12345
(these are not real URLs, i was just showing examples)
Firstly put all code for all languages under one domain - it will help your google-rank.
We have a fully multi-lingual system, with localisations stored in a database but cached with the web application.
Wherever we want a localisation to appear we use:
<%$ Resources: LanguageProvider, Path/To/Localisation %>
Then in our web.config:
<globalization resourceProviderFactoryType="FactoryClassName, AssemblyName"/>
FactoryClassName then implements ResourceProviderFactory to provide the actual dynamic functionality. Localisations are stored in the DB with a string key "Path/To/Localisation"
It is important to cache the localised values - you don't want to have lots of DB lookups on each page, and we cache thousands of localised strings with no performance issues.
Use the user's current browser localisation to choose what language to serve up.
You might want to check GNU Gettext project out - at least something to start with.
Edited to add info about projects:
I've worked on several multilingual projects using Gettext technology in different technologies, including C++/MFC and J2EE/JSP, and it worked all fine. However, you need to write/find your own code to display the localized data of course.
If you are using .Net, I would recommend going with one or more resource files (.resx). There is plenty of documentation on this on MSDN.
As with most general programming questions, it depends on your needs.
For static text, I would use RESX files. For me, as .Net programmer, they are easy to use and the .Net Framework has good support for them.
For any dynamic text, I tend to store such information in the database, especially if the site maintainer is going to be a non-developer. In the past I've used two approaches, adding a language column and creating different entries for the different languages or creating a separate table to store the language specific text.
The table for the first approach might look something like this:
Article Id | Language Id | Language Specific Article Text | Created By | Created Date
This works for situations where you can create different entries for a given article and you don't need to keep any data associated with these different entries in sync (such as an Updated timestamp).
The other approach is to have two separate tables, one for non-language specific text (id, created date, created user, updated date, etc) and another table containing the language specific text. So the tables might look something like this:
First Table: Article Id | Created By | Created Date | Updated By | Updated Date
Second Table: Article Id | Language Id | Language Specific Article Text
For me, the question comes down to updating the non-language dependent data. If you are updating that data then I would lean towards the second approach, otherwise I would go with the first approach as I view that as simpler (can't forget the KISS principle).
If you're just worried about the article content being translated, and do not need a fully integrated option, I have used google translation in the past and it works great on a smaller scale.
Wonderful question.
I solved this problem for the website I made (link in my profile) with a homemade Python 3 script that translates the general template on the fly and inserts a specific content page from a language requested (or guessed by Apache from Accept-Language).
It was fun since I got to learn Python and write my own mini-library for creating content pages. One downside was that our hosting didn't have Python 3, but I made my script generate static HTML (the original one was examining User-agent) and then upload it to server. That works so far and making a new language version of the site is now a breeze :)
The biggest downside of this method is that it is time-consuming to write things from scratch. So if you want, drop me line and I'll help you use my script :)
As for the URL format, I use site.com/content/example.fr since this allows Apache to perform language negotiation in case somebody asks for /content/example and has a browser tell that it likes French language. When you do this Apache also adds .html or whatever as a bonus.
So when a request is for example and I have files
example.fr
example.en
example.vi
Apache will automatically proceed with example.vi for a person with Vietnamese-configured browser or example.en for a person with German-configured browser. Pretty useful.