I have to add globalization (Arabic) to my English ASP.NET application.
It's been so easy to get information about the changes to be done in Visual Studio but not as easy to get information about general lines to follow (server, database, etc) and specially the changes to do in my SQL Server database. Do I need to duplicate the database? Maybe the tables?
The application is a Learning Management System: users that watch a flash movie and then they do an exam and after it they write comments and feedback. Tables are User, Organisation, Presentation, Movies, Feedback and History, plus a couple more for security.
Our idea is keep one server if it's possible but duplicate databases is allowed (I don't know if that would be an acceptable solution).
How should I proceed?
Thanks very much in advance, any help is really appreciated.
For the web application, there are a couple ways to handle localization, but you'll end up with resource files (.resx).
On the database side, decide if you only have 2 languages to support, in which case you may be able to get away with duplicating text field, or if there's the possibility of other languages, in which case you would want to have a separate table for text values, joined with a language key.
For example:
table something
pk id,
string data,
etc
table something_resx
pk id,
fk something_id
fk lang
string text
Then you'd have a query like
select data, text from something s
join something_resx r on s.id = r.something_id
where lang = lang_key
I don't know what sort of application you have, but if at all feasible I would advise that you take the localization concern entirely away from the data layer. Of course if your app is content-centric (such as a e-commerce site) it's not feasible. But if your DB only contains a few language-specific things such as country names (for example), then you could remove these and move the localization responsibility to the application layer (to keep with this example, replace the country names in your database with an ISO code, and let the application's presentation layer translate these into country names).
This is because localizing an app can depend on the localization support given to you by the .NET Framework and Visual Studio (resources files, satellite assemblies, language fallback) and many tools will help the process. At the database layer, however, you are left on your own to do everything.
Related
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.
I'm creating a web application and I just want to know how to think about Drupal's db coming from an MVC background.
I have tables to represent people's data such as SSN, First Name, Last Name, Zip Code, Address, Language, Location. Now on the front end I want to create a form to populate this information for a bunch of subjects (people). I have my database normalized so the Zip Code has its own table (with a foreign key link to the person table). The "person" table has stuff such as First Name, Last Name, Address etc... and the "language" table will have the different language abbreviations (again with a foreign key back to the person table).
I would like to know how to move something like this to drupal's schema. I know I could create my own tables and link them back to the "node" table and then I guess build my forms to accept user input...but is this the suggested way to do it? I was looking at webform, but it seems this should be used for simpler forms where the database isn't normalized and everything is just stored in one large table. I'm not sure, but I would definitely love to hear what you guys think...and if you could point me to some resources that'd be great.
Drupal is flexible enough that you can create whatever tables you want and then write code to link them back to the node table. However doing this will mean that you end up with a lot of code which is very specific to your schema, and is not very interoperable with other Drupal modules.
You will find that you get on better with Drupal if you mostly do things the Drupal way. And only go for a very customized solution where you are doing something which isn't covered by standard Drupal modules.
For example you may find that the profile module fits your needs as far as standard information about people goes. The location module (specifically user location) will cover users addresses. By using these modules you are more likely to find other modules which work with them in future and overall you will find you have less code to write.
One thing you may find useful is the migrate module for getting your existing data into Drupal.
It sounds like you're just storing information and the subjects (people) won't be users of the Drupal site.
Leveraging the node and CCK modules to make this happen would remove most of the development work. For example, each of your tables (e.g. Person, Zip Code, Language) could be represented by a content type with a number of fields. The foreign keys would be represented by node reference fields. So the Person content type may have one or more node references to nodes of type, Language.
The migrate module seems well used (626th most popular of 4000+ modules used in at least 10 distinct Drupal sites), but it may be easier to whip up your own migration script, but I'm not familiar with either your situation, your familiarity with Drupal's API, or the migrate module.
Node reference fields display as links to the referenced nodes by default, but can be themed to load and display the referenced node instead (e.g. displaying Language information in a Person node). There's a handy screencast that illustrates how to go about theming node reference fields to load and selectively display the referenced nodes' contents.
Coming from an MVC background you may not like how Drupal stores data in the DB.
Profile module was mentioned, but I find I get more flexibility with Content Profile and CCK combined.
I've written some migration scripts before from Coldfusion to Drupal, and it's not too involved.
As the question is a bit self explanatory, I want to achieve the goal of a multi-language website. I am using an Entity Data Model with MS SQL 2005. I came up with an idea of making a seperate database for each language with exactly the same model and relations. So I can use the Entities constructor that takes a connectionString and switch the site to the selected language.
I am using an ascx as the language control that fires an event, and the parent aspx gets the selected language as an integer (from event args) and call the method containing the same linq queries but Entity context will be created with the connection string of that db (of language)
I could only came up with this solution, because I think adding a new language will require a replication of the english one, imported to Access and sent to the translator. Then will be exported back, and the model will fit (HOPEFULLY).
My question is if this is really a good approach or am I missing anything that will create greater hassle to me. Thanks in advance
multi-database is not a good solution as soon as entities within the different databases have relations to each other. Generally a good approach is to work with labels in one default language. These labels can either be in a well defined format (e.g. 'LABEL.TEXT_HELLO') or just in the base language (e.g. 'Hello World').
So all you have to do is building a table for translations where the base language is the key and hopefully there is for each key a value containing the translation. As soon as you have the translations, you can write a method ont he frontend which writes the labels in the language used by the user.
In Zend Framework for example, you have to write <h1><?= $this->translate('Hello World'); ?></h1> instead of just <h1>Hello World</h1>
The good thing about that is, that if ya translation is missing, you can still use the fallback (in this case english) to show the user at least something.
That way, you can manage your app in one database and users who speak several languages do not have to switch between applications and content.
cheers
My approach: create a table Language that lists all the available languages. Relate each table that should be localized to Language. Now, you can easily access the localized content e.g.
Content[content_ID].HeadLine.Where(hl => hl.Language.id == "en-US")
I look forward to see what other people as I myself is still learning DB design and EDM.
OK, if you want to be able to easily implement a new language, then reinventing the internationalization features already built in to ASP.NET is not the way to go, because it isn't "easy".
At least, not as easy as using a satellite resource DLL. Your translators will use off-the-shelf tooling to translate your resources, and ASP.NET will automatically select the correct DLL based on the user's current culture.
Read up on ASP.NET internationalization/globalization features; there's no need to invent your own.
I'm wondering what would be the typical scenario for using an end-user report designer.
What I'm thinking of is to have a base report with all the columns that I can have, also with a basic view of the report (formatting, order of columns, etc.) and then let the user to change that format and order, take out or add (from the available columns) data to it, etc.
Is that a common way to address what is called end-user designer for reports or I'm off track?
I know it depends on the user (if it's someone that can handle SQL or not for example), but is it common to have a scenario where the user can build everthing from the sql query to the formatting?
Thanks!
Sebastian
The first thing I would think about is to put them in a very tightly controlled sandbox, both for security and also to prevent monstrous, server-eating queries. Beyond that, I think giving them a "menu" of limited options is a good path. I would not give them direct access to SQL.
First question is do you want users creating SQL that could become a run away query (think Cartesian join gone wild).
Depending upon your tooling you might want to publish your report as Excel. Creating a pivot table or a simple spreadsheet may provide the flexibility you are looking for but in a safe environment. Most users can handle removing columns, formatting, etc, in Excel and there are lots of self-help references that you might not find in a report writer tool.
Is it a bad idea (and if why?) to add a a column to the auto generated asp.net (ASPNETDB.MDF, visual studio 2008, mvc framework) "user roles - database"?
(E.g I want to add the columns RealName and LastName to the aspnet_Users table in the database.)
The reason I want to add a column instead of creating an entire new table is to avoid the doule maintenance issue and unnecessary redundancy
There are two generation schemes that are used (from Pragmatic Programmer):
Those that are used once to generate code
Those that are used all the time to have some code synced
The ones that are used for syncing, the results should not be modified, since they could be overridden at a later date when the generation gets done again.
In the case of your generated asp.net database, there is no reason for you to rerun the generation, so it would be OK to edit it.
The only scenario under which you would rerun the generation of the db is if microsoft releases a new version of the users database and you want to use the new one (in this case you might have to edit some parts of your application, so you could readd those two fields), or if you want to regenerate the database with different options. Both of these happen if you are not happy with your current db.
In my opinion that autogenerated database should be replaced by a normal table in application database or at least there should be an official solution to this problem.
I heard that this is quite good solution: http://www.asp.net/downloads/sandbox/table-profile-provider-samples/
why dont you create a new table with a Foriegn Key restraint? It seems like a bad idea to add a column to the aspnetdb...it will be a nightmare if you ever need to recreate your db...
First, those tables aren't really anything specific to MVC: they're created by/for the default AspNetSqlMembershipProvider. (Also applies to other kinds of ASP.NET applications.)
You could probably add new columns safely, but the membership provider wouldn't "see" them. It does provide its profile mechanism to store extra information (which gets serialized, and stored in the aspnet_Profiles table).
If you need to store lots of additional information about the user, you might also check out this sample membership provider that stores profile information in first-class tables, rather that in profile blobs.