Currently i have not a code-problem, but i dont know which way would be better for me.
For our project, we have two kind of data which would be translatet for the view.
The part, which be coded in the source code like system messages (e.g. You are logged in, log out, etc.)
The second part is the database content like services, there can be added or deleted rows. And not for every entity would be a translation available.
Now i need to know, if i should save and get the translation from a translation table or is it better to transfer (via script) the translation into a services.xliff file
I would suggest to use XLIFF or GetText for the application (source: php, js).
Especially http://jmsyst.com/bundles/JMSTranslationBundle might be helpful.
The storage mechanism is less important, because of caching. So feel free to use either a DB or files as backend.
User created content is often managed via database. So you might use a common DoctrineExtension, like translateable. http://symfony.com/doc/current/cookbook/doctrine/common_extensions.html
https://github.com/stof/StofDoctrineExtensionsBundle/blob/master/Resources/doc/index.rst
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 am looking to build a multilingual website using MS expressions web. The website will consist of a blog and possibly a art display portions. I would like to do all translations manually but I don't want to have more then one CSS stack. What would be the best way to populate the website text. Because this is just a learning experience I will host the website myself.
What would be the best method to implement such a website: XML or SQL.
In my professional opinion I would use SQL simply because databases are always easier to edit and handle (in my opinion...) than XML, I like KatieK's idea of simply querying a different database based on which language it is in. However, if this is a learning experience I would use whichever language you know least of b/c it will teach you more.
Also (as a side-note), if this is run locally, you have to consider the ramifications of having MYSQL database calls, it means you have to deal with server side scripting (I'm assuming you will get the XML using js, although I could be wrong), its CPU usage (although I wouldn't worry too much abut that...), and preventing mysql injection.
Finally (this is my last side-note, I swear), I know you said that you wanted to do all the translations yourself, but I thought it couldn't hurt to mention that you don't have to.
Anyway, that's my two cents.
If it were me, I'd do it using SQL. I'd have two database tables, each with the different language content, and change the SQL call server-side based on query strings.
But the best implementation method for you depends entirely on your skills and abilities. Do you have experience designing databases and writing SQL queries? Do you have a database set up right now?
I have a question about storing site configuration data.
We have a platform for web applications. The idea is that different clients can have their data hosted and displayed on their own site which sits on top of this platform. Each site has a configuration which determines which panels relevant to the client appear on which pages.
The system was originally designed to keep all the configuration data for each site in a database. When the site is loaded all the configuration data is loaded into a SiteConfiguration object, and the clients panels are generated based on the content of this object. This works, but I find it very difficult to work with to apply change requests or add new sites because there is so much data to sift through and it's difficult maintain a mental model of the site and its configuration.
Recently I've been tasked with developing a subset of some of the sites to be generated as PDF documents for printing. I decided to take a different approach to how I would define the configuration in that instead of storing configuration data in the database, I wrote XML files to contain the data. I find it much easier to work with because instead of reading meaningless rows of data which are related to other meaningless rows of data, I have meaningful documents with semantic, readable information with the relationships defined by visually understandable element nesting.
So now with these 2 approaches to storing site configuration data, I'd like to get the opinions of people more experienced in dealing with this issue on dealing with these two approaches. What is the best way of storing site configuration data? Is there a better way than the two ways I outlined here?
note: StackOverflow is telling me the question appears to be subjective and is likely to be closed. I'm not trying to be subjective. I'd like to know how best to approach this issue next time and if people with industry experience on this could provide some input.
if the information is needed for per client specific configuration it is probably best done in a database with an admin tool written for it so that non technical people can also manage it. Also it's easier that way when you need versioning/history on it. XML isn't always the best on that part. Also XML is harder to maintain in the end (for non technical people).
Do you read out the XML every time from disk (performance hit) or do you keep it cached in memory? Either solution you choose, caching makes a big difference in the end for performance.
Grz, Kris.
You're using ASP.NET so what's wrong with web.config for your basic settings (if it's per project deploy), then as you've said, custom XML or database configuration settings for anything more complicated (or if you have multiple users/clients with the same project deploy)?
I'd only use custom XML documents for something like a "site layout document" where things won't change that often and you're going to have lots of semi-meaningless data (e.g. 23553123). And layout should be handled by css as much as possible anyway.
For our team XML is a good choice (app.config or web.config or custom configuration file, it depends), but sometimes it is better to design configuration API to make configurations in code. For example modern IoC containers has in-code configuration APIs with fluent interfaces. This approach can give benefits if you need to configure many similar to each other entities or want to achive good human readability. But this doesn't works if non-programmers need to make configurations.
Due to a lack of response to my original question, probably due to poor wording on my part. Since then, I have thought about my original question and decided to reword it, hopefully for the better! :)
We create custom business software for our customers, and quite often they want attachments to be added to certain business entities. For example, they want to attach a Word document to a customer, or an image to a job. I'm curious as to how other are handling the following:
How the user attaches documents? Single attachment? Batch attachment?
How you display the attached
documents? Simple list? Detailed list?
And the killer question, how the
user then edits attached documents? Is this even possible in a web environment? Granted the user can just view the attachment.
Is there a good control library to help manage this process?
Our current development environment is ASP.NET and C#, but I don't think this is a pretty agnostic question when it comes to development tools, save for the fact I need to work in a web environment.
It seems we always run into problems with the customer and working with attachments in a web environment so I am looking for some successes that other programmers have had with their user base on how best to interact with attachments.
Start with one file upload control ("Browse button"), and use JavaScript to dynamically add more upload controls if they want to attach multiple files in a single batch.
Display them in a simple list format (Filename, type, size, date), but provide full details somewhere else if they want them.
If they want to edit the files, they have to download them, then re-upload them. Hence, you need a way that they can say "this attachment overrides that old attachment".
I'm not familiar with C# and ASP.NET, so I can't recommend any libraries that will help.
http://developer.yahoo.com/yui/uploader/
I am looking for guidance regarding the best practice around the use of the Profile feature in ASP.NET.
How do you decide what should be kept in the built-in user Profile, or if you should create your own database table and add a column for the desired fields? For example, a user has a zip code, should I save the zip code in my own table, or should I add it to the web.config xml profile and access it via the user profile ASP.NET mechanism?
The pros/cons I can think of right now are that since I don't know the profile very well (it is a bit of a Matrix right now), I probably can do whatever I want if I go the table route (e.g., SQL to get all the users in the same zip code as the current user). I don't know if I can do the same if I use the ASP.NET profile.
Ive only built 2 applications that used the profile provider. Since then I have stayed away from using it. For both of the apps I used it to store information about the user such as their company name, address and phone number.
This worked fine until our client wanted to be able to find a user by one of these fields.
Searching involved looping through every users profile and comparing the information to the search criteria. As the user base grew the search time became unacceptable to our client. The only solution was to create a table to store the users information. Search speed was increased immensely.
I would recommend storing this type of information in its own table.
user profile is a nice clean framework for individual customization(AKA. Profile Properties). (e.g. iGoogle)
the problem of it is its not designed for query and not ideal for data sharing to public user.(you still would be able to do it, with low performance)
so, if you want to enhance the customized user experience, user profile would be a good way to go. otherwise, use your own class and table would be a much better solution.
In my experience its best to keep an the info in the profile to a bare minimum, only put the essentials in there that are directly needed for authentication. Other information such as addresses should be saved in your own database by your own application logic, this approach is more extensible and maintainable.
I think that depends on how many fields you need. To my knowledge, Profiles are essentially a long string that gets split at the given field sizes, which means that they do not scale very well if you have many fields and users.
On the other hand, they are built in, so it's an easy and standardized way, which means there is not a big learning curve and you can use it in future apps as well without needing to tweak it to a new table structure.
Rolling your own thing allows you to put it in a properly normalized database, which drastically improves performance, but you have to write pretty much all the profile managing code yourself.
Edit: Also, Profiles are not cached, so every access to a profile goes to the database first (it's then cached for that request, but the next request will get it from the database again)
If you're thinking about writing your own thing, maybe a custom Profile Provider gives you the best of both worlds - seamless integration, yet the custom stuff you want to do.
I think it is better off using it for supplementary data that is not critical to the user that is only normally important when that user is logging in anyway. Think data that would not break anything important if it was all wiped.
of course thats personal preference but others have raised some other important issues.
Also very useful considering it can be used for an unauthenticated user whose profile is maintained with an anonymous cookie.