For example, there is an entity "book" with the attributes "title" and "description".
There are plenty books stored in the database. The information is stored in english. Now I'd like to publish this app in e.g. 10 different countries (10 different languages).
Is there any way to handle this with NSLocalized* or is it necessary to extend the database, that every stored entity must be created for each language?
I think when doing this with a Localizable file, it gets unbelievable huge and chaotic.
What is the best practice for this?
My first question is will this data change during the life of the app? If the answer is yes, then you will encounter issues with NSLocalized because you would have to update the app to include translated strings.
Otherwise, maintaining 10 different databases is a recipe for disaster. A few quick searches can cover this in agonizing detail.
Assuming then that the data will be static with each release, I would recommend that you take a different approach and create a single books.plist file that contains your data. This gives you the benefit of being able to localize the file, without the need to maintain a separate strings file to feed into your localization calls. Using this approach requires just one source of truth and supports your localization needs. Additionally, if you support copying it into the users documents directory, it can also be updated over time as your list evolves.
Related
I am building an iOS application that will randomly generate sentences (think Mad Libs) where the data used for generation is in multiple tables. This will be used to generate scenarios for training lifeguards. Each table contains an item name, the words that will be used when selected, and different values that determine what can go togeather.
Using two of the 10 tables shown above, the application may pick a location of Deep Water. Then it needs to pick an appropriate activity for in the water, such as Breath holding, but not Running.
I have been looking at Core Data for storage but that seems to be more for data that is changing often by the user and users would never change the data stored. I do want to be able to update the tables myself fairly easily. What would be the optimal solution to do this? The ways I think of are:
Some kind of SQL DB, though my tables again aren't changing and
aren't relationshipable.
2-D arrays written into the source code. Not pretty to work with or read, but my knowledge of regex makes converting from TSV to array fairly easy.
TSV files attached to the project. Better organization itself but take some research on how to access.
Some other method Apple has that I do not know about.
In our web site we use .resx files to provide labels and GUI in 4 different languages (English, Spanish, French and German). A specific department is in charge to provide translations, given the english values (default).
We, as programmers, define english translations and send them to the language department in a specific day. Usually after a week we get the translated list back and we integrate it in the solution.
However between the date we send the list out and we get it translated, it might happen that new labels are created (usually between 10 and 20 entries) and managed internally by another department to save time.
What would be the best practice to manage and process the "delta" entries that need to be translated and then integrated in the labels list?
How current approach is try to sort the .resx files and then compare them to find out the new fields missing a translation. But I guess there is a better approach for this.
I'm working for the Translation Agency Supertext and we often have this problem too. But most translation departments use tools like Trados, MemoQ,etc. They all have built in Translation Memories. E.g. everything that has already been translated once, can automatically be translated again.
In your case, you should be able to just send them the files again and they can just add the missing translations. If your department is not using any tools, I would have a serious word with them...
Alternative there are online tools like transifex, where you could actually manage this process yourself. There are other similar tools, but would have to dig them up.
In any case, the core of the message is that you use a TM (Translation Memory).
I am planning on developing a data intensive application for medical guidelines, these guidelines will need updating every so often so there will be a requirement to update them myself as the developer. One option is to put the data in a plist but I find this approach quite tedious. I was thinking of using chunks of HTML and referencing the files in my application, this way they would be a lot easier to edit.
I am curious to know how the interface below has been generated or what options I have available to generate a similar interface, is HTML the best option here or native UI elements with either Core Data + Core Text or SQLite + Core Text? Bearing in mind that I want an easy way to update the data and the data must be available to the app whilst offline?
Bearing in mind that I want an easy way to update the data and the
data must be available to the app
I would go with plists. I think they are quite good to hold your data and to be edit by any person (non IT related person, with HTML they would have to be careful with tags). HTML files although ok, don't think it's as good as plists, since on the last one, you immediately understand the hierarchy if you structured it correctly, while on HTML is just a bunch of files. As for the view, I do think a UITableView with some custom UITableViewCells would do the trick (I find the interface a bit ugly to be honest).
I would go with SQLLite database, which you can frequently update from your server.
I have also created a medical app and oftenly need to update the data, so I designed it on SQLLite.
I check at program startup if a new version of the DB is available and if it is I'm downloading it on the App replacing the old version.
Just keep in mind that you need to keep a record in your App about the DB version it is running and whenever you update it you need to update the db version key on your App as well.
I would also suggest to create an editable version of the SQLLite DB in case you want to allow the users to store data to it, by copying the database from the app bundle to the users documents dir.
I'm trying to figure out the cut-off with respect to when a "text entry" should be stored in the database vs. as a static file. Are there any rules of thumb here? The text entries will be at the most several paragraphs and have links to images and tables (and hyperlinks to other text entries). Some criteria for the text entry:
I'm thinking of using DITA as the content format
The text should be searchable
If the text is revised, a new version will be created
thanks in advance, Chuck
The "rails way" would be using a database.
The solution will be more scalable, therefore faster and probably easier to develop with (using migration and so on). Using the file system, you will have to build lots of functions on your own, that are already implemented for database usage.
You could create a Model (e.g.) Document and easily use existing versioning systems, like paper_trail. When using an indexed search, you can just have an has_many relation enabling you to realise the depencies between the models (destroy a model means to destroy the search index).
Rather than a cut-off, you could look at what databases provide and ask yourself if those features would be useful. Take Isolation (the I in ACID): if you have any worries that multiple people could be trying to edit an entry at the same time, a database would handle that well while you'd have to handle the locks yourself working with files. Or Atomicity: you might want to update two things at once (e.g. an index page and an entry page) and know they will either both succeed or both fail.
Databases do a number of things beyond ACID, such as taking advantage of multiple datatypes, making querying easier, and allowing for scaling. It's a question worth asking since most databases end up having data stored in a bunch of files on disk. Would you end up writing a mini-database if you used files yourself?
Besides, if you're using rails you mind as well take advantage of its ActiveRecord functionality, and make it possible to use the many plugins that expect a database.
I'd use a database for even a small, single user rails app.
I believe several of us have already worked on a project where not only the UI, but also data has to be supported in different languages. Such as - being able to provide and store a translation for what I'm writing here, for instance.
What's more, I also believe several of us have some time-triggered events (such as when expiring membership access) where user location should be taken into account to calculate, like, midnight according to the right time-zone.
Finally there's also the need to support Right to Left user interfaces accoring to certain languages and the use of diferent encodings when reading submitted data files (parsing text and excel data, for instance)
Currently I'm storing all my translations for all my entities on a single table (not so pratical as it is very hard to find yourself when doing sql queries to look into a problem), setting UI translations mainly on satellite assemblies and not supporting neither time zones nor right to left design.
What are your experiences when dealing with these challenges?
[Edit]
I assume most people think that this level of multiculture requirement is just like building a huge project. As a matter of fact if you tihnk about an online survey where:
Answers will collected only until
midnight
Questionnaire definition and part of
the answers come from a text file
(in any language) as well as
translations
Questions and response options must
be displayed in several languages,
according to who is accessing it
Reports also have to be shown and
generated in several different
languages
As one can see, we do not have to go too far in an application to have this kind of requirements.
[Edit2]
Just found out my question is a duplicate
i18n in your projects
The first answer (when ordering by vote) is so compreheensive I have to get at least a part of it implemented someday.
Be very very cautious. From what you say about the i18n features you're trying to implement, I wonder if you're over-reaching.
Notice that the big boy (e.g. eBay, amazon.com, yahoo, bbc) web applications actually deliver separate apps in each language they want to support. Each of these web applications do consume a common core set of services. Don't be surprised if the business needs of two different countries that even speak the same language (e.g. UK & US) are different enough that you do need a separate app for each.
On the other hand, you might need to become like the next amazon.com. It's difficult to deliver a successful web application in one language, much less many. You should not be afraid to favor one user population (say, your Asian-language speakers) over others if this makes sense for your web app's business needs.
Go slow.
Think everything through, then really think about what you're doing again. Bear in mind that the more you add (like Right to Left) the longer your QA cycle will be.
The primary piece to your puzzle will be extensive use of interfaces on the code side, and either one data source that gets passed through a translator to whichever languages need to be supported, or separate data sources for each language.
The time issues can be handled by the interfaces, because presumably you will want things to function in the same fashion, but differ in the implementation details. To a large extent, a similar thought process can be applied to the creation of the interface when adjusting it to support differing languages. When you get down to it, skinning is exactly this, where the content being skinned is the interface, and the look/feel is the implementation.
Do what your users need. For instance, most programmer understand English, there is no sense to translate posts on this site. If many of your users need a translation, add a new table column with the language id, and another column to link a translated row to its original. If your target auditory contains the users from the Middle East, implement Right to Left. If time precision is critical up to an hour, add a time zone column to the user table, and so on.
If you're on *NIX, use gettext. Most languages I've used have some level of support; PHP's is pretty good, for instance.
I'll describe what has been done in my project (it wasn't my original architecture but I liked it anyways)
Providing Translation Support
Text which needs to be translated have been divided into three different categories:
Error text: Like errors which happen deep in the application business layer
UI Text: Text which is shown in the User interface (labels, buttons, grid titles, menus)
User-defined Text: text which needs to be translatable according to the final user's preferences (that is - the user creates a question in a survey and he can also create a translated version of that survey)
For each different cathegory the schema used to provide translation service is different - so that we have:
Error Text: A library with static functions which access resource files
UI Text: A "Helper" class which, linked to the view engine, provides translations from remote assemblies
User-defined Text: A table in the database which provides translations (according to typeID of the translated entity and object id) and is linked to the entity via a 1 x N relationship
I haven't, however, attacked the other obvious problems such as dealing with time zones, different layouts and picture translation (if this is really necessary). Does anyone have tackled this problem in a different way?
Has anyone ever tackled the other i18n problems?