My Android app connects to a asp.net web service to register the user. When the user is registered I send a welcome email from the server to the user. As we have customers in many countries the email need to be translated into the right language. I use the following code (C#) on the server to get the body of the email:
string mailbody = (string)HttpContext.GetGlobalResourceObject("Resource", "mailbody");
In my App_GlobalResources-folder I have a file containing the English translation called Resource.resx and for the Swedish translation Resource.sv.resx.
Many English users are now complaining about that they get the Swedish translation sent instead of the English translation. Every time I test this on my Android phones I get the right translation so it is hard for me to track this error down. Also this has been working great when connected from iPhone. Any ideas what can be wrong? Have anyone seen a problem like this?
The behavior you describes seem pretty odd. It seems to be related to Culture detection in your web service and of course web.config might play a role here.
However, setting culture and uiCulture to "auto" should detect the most desired culture from web browser, that is I don't think it should be Swedish for English user... I would suspect some strange fall-back rule.
Are you really sure your neutral-culture resources (Resource.resx) are in English (just to double check that)?
Maybe you have some overrides in Global.asax?
If the answer for both question is "it's OK", maybe try to modify settings to uiCulture="auto:en-US" so that language falls back directly to English (United States). With no other resources and neutral culture resources in English, it should, but...
Related
I stumbled upon some strange behaviour today on a website at work. Our SEO consultant wanted some strange looking links taken away from Googles index, a seemingly straight-forward task. But it turned out to be very difficult.
The website was a .net MVC 5.2.3 application. We looked at routing, our own libraries etc. Nothing strange. After a while we gave up and tried simply redirect request to these urls by setting up a rule in web.config. Turns out these URL:s are unmatchable! Somehow under the right conditions the critical part of the URL seem to avoid matching rules as well as routing later on in the MVC application.
We narrowed down the mystical URL:s to the format (T(anything)) where T can by any capital letter and anything can be eh, anything. This is placed in the beginning of the URL as if it were a directory. In regex: \([A-Z]\([a-zA-Z0-9]*\)\)
I've tested and found the same behaviour on:
.net MVC5 sites
.net MVC3 sites
.net Web Forms sites
http://asp.net
http://stackoverflow.com
Some examples from stackoverflow.com:
Bypasses routing: https://stackoverflow.com/(K(jonas))/questions
Routes normal (404): https://stackoverflow.com/jonas/questions
Bypasses routing: https://stackoverflow.com/(G(hello))/users/1049710/jonas-%C3%84ppelgran
Routes normal (404): https://stackoverflow.com/gandhello/users/1049710/jonas-Äppelgran
It doesn't seem to affect the whole web, so it shouldn't be a browser or HTTP issue. Some examples:
Routes normal (404): http://php.net/(T(testing))/downloads
Routes normal (404): https://www.iana.org/(T(testing))/domains/reserved
Can anybody explain what is going on?
And what I can do to prohibit these URL:s to bypass routing?
Apparently this is a feature called a "cookieless session" in ASP.NET. See "Cookieless SessionIDs" section here in the MSDN docs.
The basic idea is that instead of storing the session id (if session state is enabled) in a cookie, it's now embedded in the URL.
We (Stack Overflow) disable session state entirely (by setting sessionState mode to off). As far as I know, the end result is that any time one of the URLs that match the session id format is used, that information is simply discarded.
None of the links leading to us in Google include it either, which makes me think that your site may be configured to actually generate session IDs in URLs? Short of disabling the feature, there's probably not much you can do here. Although, see "Regenerating Expired Session Identifiers" on the MSDN page I linked above to see how to at least prevent accidental session sharing if that's not already done.
I have a weird issue here, and I'm not sure if its ASP.NET versions, IIS, or me doing something stupid (experience tells me its probably item 3.)
I have 2 websites that worked fine on w2k3, 1 is ASP.NET 1.1, and the other 2.0, with the currency being displayed correctly on web pages.
Since migrating these to a w2k8 box and IIS 7 I have an odd issue where the 1.1 site is now displaying $ rather than the local currency that the user browses to. But the 2.0 site works fine.
Both have IIS set to the same globalisation. (No culture, Client is false, UI Culture is English (en)).
Both sites are hosted on the same server, the only differences I can see are that;
1 binds using <Databinder.Eval(... Price, "{0:c}")> and the other binds to a property that uses String.Format("{0:c}");
So being as the code has not changed I feel that it is an IIS issue. But as both sites have the same globalisation settings in IIS I don't see that it can be.
So, anyone know whats goign on and how to solve it?
Running IIS 10 site that was developed on a UK machine server 2012 was moved to a GCP default build server 2016 which comes US "out of the box".
On the website $ signs appear where £ signs used to.
I changed everything I could in Settings > Region and Language. UK language, keyboard, Update & Security, Drive on Left etc. Absolutely nothing made any difference.
Finally found it in Control Panel > Region. After adding English UK as a display language (and gettting rid of US English)
I needed to go to Adminstrative Tab, Welcome Screen and new User Accounts. Copy the settings.
Now the site is finally displaying correct currency symbol.
Check the Regional and Language options from control panel on the new server and make sure they match the like setting on the old box.
AFAIK, at least String.Format("{0:c}") and probably <Databinder.Eval(... Price, "{0:c}")> as well will use whatever the value of property System.Threading.Thread.CurrentCulture is.
It does not matter whether or not you set it on the page, the value will be assigned to it anyway. And it is pretty reasonable to think, that these settings will come from server settings, which from your description seems to be en-US. Thus $ as currency sign... You might ask yourself why it was working before...
Well, are you sure that you have copied all the configuration files?
Another clue might be, that you have emulated version of .Net 1.1 rather than the real one on your new box. It might be not 100% compatible...
I have an installable ASP.Net application that is logging using Common.Logging.
When writing log messages ie:
_log.InfoFormat(CultureInfo.???, "{0}: Writing to the Log", DateTime.UtcNow);
I am confused about which culture I should be using. The result I want is that the log messages are formatted using the server's regional settings. That way when administrators install the application they have control over how their log messages are formatted.
There are fours options but none seem to be the correct choice:
CultureInfo.CurrentCulture: this seems like it would be the correct choice for a windows app but ASP.Net is changing this to match the user browsing the site - so it's appropriate for formatting content to display to the user but not for writing to the log.
CultureInfo.CurrentUICulture: similar problems to CurrentCulture - will match the current user browsing the site.
CultureInfo.InstalledUICulture: the system installed culture - appears to relate to the copy of windows installed but not alterable by the user. Apparently this one is a bit useless
CultureInfo.InvariantCulture: this is not user configurable. I am wondering if this is the best of the four options here though because at least it is consistent and won't vary by who is browsing the site/the media windows was installed from.
I am left wondering if I need to add explicit configuration in my web.config for the system culture so the installer can choose a culture. The answer I really want is whatever CultureInfo.CurrentCulture was before ASP.Net changed it to match the current user.
Note: I know I can turn off ASP.Net changing the CurrentCulture per user but the UI relies on this behaviour.
Admins like to have control over the logs. Telling them to go configure their server culture so that the logs are in a particular format doesn't seem like the best solution to me.
Adding a configuration option into web.config is a good idea. This will let the admin configure the log format as required.
Rather than ask the user, you could make an intelligent guess while installing using CultureInfo.CurrentCulture. If the user wants it to be something different, he can always change it.
If you do want to take it from CultureInfo.CurrentCulture rather than configuration, you can pick it during the Application_Start event, and keep it in the application context.
I am tasked with developing a multi lingual site using ASP.NET MVC. For static content i am ok to have resx files to allow better scalability. But the problem comes for user entered data. User1 fills up a customer data form and saves it using language1. Now User2 when views the data, the data entered by user1 in langauge1 should be shown in the language of User2's choice. Can somebody help with some idea here. Thanks in advance.
You could use an automatic language translation service such as Google's Translate. Using it as simple as sending a GET request to https://www.googleapis.com/language/translate/v2?key=INSERT-YOUR-KEY&q=hello%20world&source=en&target=de (translates hello world from English to German) and parsing the resulting JSON.
As pointed out by #olivehour, Microsoft also offers a similar service.
Don't expect miracles though as far as the quality of the automatic language translation is concerned.
If you want the user inputted data translated into other users languages, you should request them to input it in those other languages. Or get editors to do that for them, assuming you want some level of quality in the translations.
This is a pretty basic question.
Since browsers have a culture setting that the web app uses to decide which locale to use, should I still have a "language" button for users to be able to override the culture?
Why or Why Not?
To me it doesn't make sense to have a button there if the user had already set their language in their system.
Yes, you should.
One of the reasons outlined on the ASP.NET Localisation page is that a user may have a preference for reading certain types of websites in a specific language (i.e. technical websites in English). This is a good reason.
There are other reasons as well (i.e. the translation may not be great, a different user than typical is using the given computer, etc, etc).