I have some SSRS 2008 reports that need to be localized. That is:
Report titles, column headers, etc. all need to be in the user's locale. (Note that in my situation, the User!Language expression may or may not be useful, but that's not the major problem.)
The localized strings must be retrievable from a table within the same DB as the actual report data. Separate localized RDLs won't work for us. Localization will be managed by non-developers, so we've provided a UI for them to change localized strings themselves.
We'd very much prefer not to retrieve strings through a custom assembly, if we can help it. We've had trouble in the past deploying custom assemblies, and of course it introduces some debugging complexity as well.
All ideas are welcome.
I guess you just need a table on the db with everyone's country preference against their user ID. Then based on the user ID you can set the formatting accordingly.
Pretty bad practice though. Why can't you use User!Language?
Related
I need to do something like:
Show list of countries >> Select country -> show list of Cities.
So I have to get a list of cities by country but without using data in database.
Can anyone please suggest me a solution ?. I really appreciate your help.
You could use an API but the problem is that you will have a request everytime your page load. Not every API provider will allow this. For example, Here is an API that gets Country / Cities.
Another solution as you are using .NET technologies is to use a localDB. A localDB is in fact a database but within your app. Have a look to the definition on the MSDN :
It is very easy to install and requires no management, yet it offers the same T-SQL language, programming surface and client-side providers as the regular SQL Server Express. If the simplicity (and limitations) of LocalDB fit the needs of the target application environment, developers can continue using it in production, as LocalDB makes a pretty good embedded database too.
Finely, the last solution that comes in mind if you can't use XML or JSON files nor a LocalDB is to have your lists in classes but in my opinion you should avoid this solution, it will simply load everything in RAM until you application stops, as HDD cost less that RAM I really think the better option is to use XML or JSON files in your app.
You can store the info into a text file or even into a static class in your code (not exactly a great idea, but doable).
Then you just need to get the info from the container and build two SelectList items, one for countries and one for cities.
Use javascript to link change event of countries SelectList to a filtered reload of cities SelectList
Assuming you have a preset list of cities by country, and you really cannot use any sort of database, then perhaps just use text files? One text file for the list of countries and then one file per country with the list of cities. Read in the text file and display as needed.
This question may seems odd but we have a slight mixup within our Report Suites on Omniture (SiteCatalyst). Multiple Report Suites are generating analytics and it's hard for us to find which site URL is constituting the results.
Hence my question is, is there any way we can find which Site is filling data within a certain Report Suite.
Through this following JS, I am able to find which "report suite" is being used by a certain site though:-
javascript:void(window.open("","dp_debugger","width=600,height=600,location=0,menubar=0,status=1,toolbar=0,resizable=1,scrollbars=1").document.write("<script language=\"JavaScript\" id=dbg src=\"https://www.adobetag.com/d1/digitalpulsedebugger/live/DPD.js\"></"+"script>"));
But I am hoping to find the other way around that where Report Suite gets its data from within the SiteCatalyst admin.
Any assistance?
Thanks
Adobe Analytics (formerly SiteCatalyst) does not have anything native or built in to globally look at all data coming to see which page/site is sending data to which report suite. However, you can contact Adobe ClientCare and request raw hit logs for a date range, and you can parse those logs yourself, if you really want.
Alternatively, if you have Data Warehouse access, you can export urls and domains from there for a given date range. You can only select one report suite at a time but that's also better than nothing, if you really need the historical data now.
Another alternative is if your sites are NOT currently setting s.pageName, then you may be in some measure of luck for your historical data. The pages report is popped from s.pageName value. If you do not set that variable, it will default to the URL of the web page that made the request. So, at a minimum you will be able to see your URLs in that report right now, so that should help you out. And if you define "site" as equivalent of "domain" (location.hostname) you can also setup a classification level for pages for domain and then use the Classification Rule Builder and a regular expression to pop the classification with the domain, which will give you some aggregated numbers.
Some suggestions moving forward...
I good strategy moving forward is to have all of your sites report to a global report suite. Then, you can have each site also send data to a site level report suite (warning: make sure you have enough server calls in your contract to cover this, since AA does not have unlimited server calls). Alternatively, you can stick with one global report suite and setup segments for each site. Another alternative is to create a rollup report suite to have all data from your other report suites to also go to. Rollup report suites do not have as many features as standard report suites, but for basic things such as pages, page views, it works.
The overall point though is that one way or the other, you should have all of your data go into one report suite as the first step.
Then, you should also assign a few custom variables to be output on the pages of all your sites. These are the 4 main things I always try to include in an implementation to make it easier to find out which sites/pages are reporting to what.
A custom variable to identify the site. Some people use s.server for this. However, you may also want to pop a prop or eVar with the value as well, depending on how you'd like to be able to break data down. The big question here is: How do you define "site" ? I have seen it defined many different ways.
If you do NOT define "site" as domain (e.g. location.hostname) then I suggest you pop a prop and eVar with the domain, because AA does not have a native report for this. But if you do, then you can skip this, since it's same thing as point #1
A custom prop and eVar with the report suites(s). Unless you have a super old version of legacy code, just set it with s.sa(). This will ensure you get the final report suite(s), in case you happen to use a version that uses Dynamic Account variables (e.g. s.dynamicAccountList).
If you set s.pageName with a custom value, then I suggest you pop a prop and eVar with the URL. Tip: to save on request url length to AA, you can use dynamic variable syntax to copy the g parameter already in a given AA request. For example (assuming you don't have code that changes the dynamic variable prefix): s.prop1='D=g'; Or, you can pop this with a processing rule if you have the access.
you can normally find this sort of information in the Site Content-> Servers report. There will be information in there the indicates what sites are sending in the hits. Your milage may vary based on the actual tagging implementation, it is not common for anyone to explicitly set the server, so the implicit value is the domain the hit is coming in from.
Thanks C.
I have few values that are DB driven/or coming from other system which i dont have control of, So how to apply globalization in this case? I really dont trust on translation service apis that are provided from google or microsoft as i dont want any mistranslation happening anywhere in application leading to great embarassment to user.
So what is the best solution to tackle this schenario?
Thanks in advance.
Don't expect miracles and don't look for a function in .NET called string Translate(string input, string inputLanguage, string outputLanguage). If you don't want to use third party translation services because you don't trust them and you have no control over the data publisher so that it provide you with translations of the content on different languages there's really not much you could do. If it's simple words you could keep a dictionary in order to perform the translation on the fly but that will be impractical for whole sentences.
I have encountered this in one of my products and what I did was to allow in the database design room for A)"native"/"original" + B)zero-ormany translations/localiazations of each such value. I've got in place a back end interface that allows for translating these values. That could be purely human-driven, or a combination of automatic translation with human verification.
Building an asp.net mvc website that has to be multilingual and wondering if it's possible to store formatted text in a resource file and whether it makes sense.
Lots of pages are static and user can edit them and add their own formatting "Bold,italics etc.."
and was wondering what is the best way to approach it.
I dont want to create one page x language and storing in the database involves creating a structure to handle the same info in multiple languages.Seems hard to maintain.
Have you done it before? How did you do it
any suggestions
Thanks a lot
Is it possible?
Certainly.
Does it make sense?
It depends. I would not recommend resource files (via ResourceWriter) for storing dynamic content.
Your problem
Let me rephrase it (I am not sure if I understood you correctly). You want to give your users an ability to change presentation style. User will be able to change the style and that change would be somehow propagated to whatever languages the content is translated to.
In such case, I see some issues:
How to match English contents with translated one?
It is typical for translation to have different order and possibly different number of sentences. There is no way to match them unless...
Storing such information in resource files along with translatable strings would result in something that is hard to maintain. I believe you would need to either add formatting tags or content tags with styling information in order to achieve that. The result would be a mess; hardly readable, as tough to modify.
OK, so what can you do? Actually, what I could recommend is to create Customization Mechanism for CSS files. In your case you need:
Provide CSS classes as well as unique identifiers (HTML id attribute) to each structural elements (tags if you prefer), so that you have something like <div id="main" class="main"><p id="p1" class="normal">.... The id's will give users an ability to target precisely that element leaving others untouched (via #p1.normal { // definition here }).
Store CSS in the Database and create some editor for users.
Create a Handler to serve CSS from database upon web browser's request.
Even with such solution you won't avoid some problems. One is that you need to actually alter font family while translating into certain languages, so you might need language-based CSS files. Another problem pops up when user wants to put bold attribute on certain word - with such solution this is not possible (but to be honest if you want to allow that, this won't be i18n friendly for the reasons I mentioned earlier).
BTW. Bold fonts should be avoided for some languages. For example Chinese characters are pretty hard to read if you manage to output them with bold font.
If your users can post in multiple languages - its probably best to use a database to store the info and accompanying formatting. If it is for labels and other static text on the website - the resource files are a good solution. The resource files store the content as strings - but storing formatted text in there breaks the 'seperate the presentation from the logic' idealogy.
I'm building a publicly available web app. Because of this, I'll be validating every field as exhaustively as I can. I mean, if someone enters something that isn't valid, they will know exactly what it was (making it clear what they need to fix).
I've followed Scott Guthrie's examples in the NerdDinner eBook. I love the idea of having all my validation in the core class files (as a partial class).
The validation I'm performing is this:
Min value - make sure strings are at least a certain length
Max value - make sure strings are under a maximum length (based on field properties in the DB)
int checks - make sure integer fields can be correctly parsed to int
file extension - make sure the uploaded file extensions are of the correct type
My question is, what are the typical validation checks you make in your web apps? Maybe I'm completely overlooking something. ;)
Thanks in advance!
You should try to use existing frameworks as much as possible for validation. Writing a comprehensive validation library is a lot of hard and time-consuming work. It's one of those things that are best left to a team of people dedicated to developing it such as the jQuery validation plugins and projects like that. There are a lot of really nice validator libraries out there already that could save you a lot of time and effort.
There is an MVC validator toolkit project on codeplex you may find helpful. CodeProject has a tutorial on it if you want to read more into it. You can also check out xVal, as one of the commenters mentioned.
If you have a specific reason you need to write validation in-house, or you aren't convinced by what I said above, a few that I find useful are:
Required field validation, obviously. You might already have this by just checking for minimum length in your fields.
Generic regular expression validation. Make sure you have some way to perform this kind of validation generically. This will help you in case there is some specific field that needs a unique form of validation found no where else in your site. Make sure your API is flexible enough to add specific regular expression based validation.
Email. You'll need this.
Phone numbers. These can be tough because of all the forms they can come in (all numeric, sometimes with alpha characters, sometimes international numbers that follow different formats)
Dates & times are important also, however you should consider using some sort of date/time picker to reduce the possibility of error by not allowing the user to type a value.
Make sure you include validation capabilities for non-textbox related fields, such as drop-down lists, radio buttons, check boxes, etc. I've forgotten these in the past just out of oversight, but they do become important.
Matching fields. For example, when confirming a password, both fields should match. This won't be used in just one page. Think about password resets, administrative pages, user control panels, etc.
Although somewhat complex, you might also want to include sequence validation. For example, perhaps some options on your site require you to select other options first. Another example is that certain options should only be selectable if you first choose some other combination of options. This is something that you may not be able to include in a generic API, but it's something to think about.
You'll want to check for SQL injection, XSS, and CSRF. You can use these tools for Firefox to help you test those. Then there are also things like making sure that the username doesn't equal the password, login throttling, etc. Validating your CSS and XHTML isn't bad either, though I don't think that's quite what you meant.
In addition to what others have mentioned, don't forget to validate items that depend on one another. That is, consistency of input values. If the user enters a maximum and a minimum, for example, don't just check the two values independently against their legal max and min, but also check them against each other to ensure that the values entered are logically consistent.
For hostnames, you may want to validate that DNS returns an IP address. If it does not, let the user know but don't necessarily reject the hostname for this reason. Maybe the user is pre-configuring something that doesn't exist yet. It depends on the specific application.
That is, in addition to syntactic validity, you can also check that the values entered are meaningful and consistent with each other.
Another thing you can do if you go all out is to only allow digits to be entered in numeric fields, only allow digits and "-" in credit card or phone number fields, and so on.
And always, always allow the user to enter input in the most familiar format, even if you later have to strip out extraneous data. For example, let the user (but don't require the user to) enter a phone number is 1-800-555-1212 even if you later strip out the "-" characters.
Not really sure what this has to do with asp.net-mvc but...
I always try to avoid over-validating (obviously you need to do the simple sanity stuff to make sure there are no db errors). It is a field by field decision according to your business rules. Some fields will need to have strict validation rules, like a credit card number. But just always think about how the validation will server the user. There is rarely a need for the regex to match all possible email addresses - it is really annoying when a site won't allow + signs in your email. In most cases, your app will be just fine if you let people put in phone numbers how they want. And always second guess yourself when you're about to put a required rule on a field.
I recommend the entlib validation application block for a easy to use and extend framework.