Hi I would like to have some suggestion about the internazionalization of my app:
let's consider the app uses a DB to retrieve a set of question to propose to the user. Such questions should be translated in different languages.
I have considered two approaches:
One DB with the Table "Question". The table contains a column for each language I would like to support. (I dislike this approach since in the case i want to add in future new languages i should modify something already working)
More DB schema. Each DB schema is dedicated to a language seem better approach
Do you have any experience about the best solution to adopt?
do you have any other solution to suggest?
Thank you and kind regards
If you really want to keep the questions in a DB, I would recommend only storing keys used by NSLocalizedString macro, and the actual translations in dedicated localisation files (.string) - as #Adam Richardson suggested. This way you can update the individual translations (or add new ones) without touching the DB itself.
Hi due to a deeper research i have found this topic How to represent a localized string type in Core Data? i'm going to adopt the tecnique suggested as a solution.
kind regards
Nicolò
Related
tl;dr How should I approach storing code blocks in a react + rail application? If I were to store the code block data in the rails backend, which datatype should I store it as? And if on the frontend, would mdx files be the best solution?
I’m building a programming quiz application where a question has many answers and each answer (only one is correct) has an explanation. The question consists of the question itself and a code block, similar to what’s circled in orange in this wireframe.
As I want to practice building Rails+React (Next.js) applications, I thought that the questions would be stored on the backend. However, is that a good idea? If so, I’m wondering about what would be a possible way to store the code snippets given the Rails datatypes?
Alternatively, I was also considering storing all the questions on the frontend. If I choose to do so, would mdx files be the best solution here?
So, to sum up, which of the following solutions would be best here:
Storing code block as markdown files in the frontend
Storing code block data in the backend
Different solution altogether?
I thought that the questions would be stored on the backend. However, is that a good idea?
This depends on if you want the questions and answers to be user editable. In that case you need to actually store it somewhere. That somewhere would typically be a database which your Rails app communicates with.
If you're using markdown you can use the :text type in ActiveRecord. The database adapter will map this to a suitible type for that database for storing long strings - the exact details vary per adapter.
Alternatively, I was also considering storing all the questions on the
frontend. If I choose to do so, would mdx files be the best solution
here?
If by "storing the questions on the frontend" you mean putting them into your react project and serving them through that server (or cloud storage) then that is definately an option if you're building a very simple application where the questions and answers are a developer concern.
TLDR;
You really need to write use cases and goals for your application. If its a learning application do you really want to learn more about the server side and writing database applications or do you want to focus on writing client side code? The answer to those questions will determine your choices.
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.
I'm brand new to Swift/programming in general. I want to make a drug reference app for iOS specific to my field (anaesthesia) as a hobby project which could potentially be useful.
Each drug will have a multitude of properties by which they can be grouped (eg chemical structure, receptor acted upon) or which can be searched (eg all opioids which do not contain preservatives).
It would look something like this: https://itunes.apple.com/us/app/drugs-medications/id337974028?mt=8
I think it would make most sense to use a read-only relational database, which would take data from an external source (eg XML).
My questions are:
What should I be reading about to implement this in Swift? SQLite? Core Data? Simplicity trumps performance I think.
How can data entry be made easier? I'd be most familiar with exporting XML from Access, but I'm sure (much) better options exist.
Thanks in advance
What should I be reading about to implement this in Swift?
The Swift Programming Language: documentation about Swift
iOS resources: documentation about iOS
Core Data: documentation for the Apple-blessed database
GRDB.swift: documentation for an SQLite application toolkit
https://www.raywenderlich.com: a website full of tutorials.
Simplicity trumps performance I think. [...] How can data entry be made easier?
Make your app first: it looks useful. Make it better only then: the users of your app don't really care how it is implemented.
I am looking for someway how to preserve methods which I add to my classes which are generated from Core Data. It should be mainly init methods but It could be other methods too. When I was looking best approach for this I found this question but It's a little old and I hope there is better solution now. So exists better solution?
I think creating Categories like suggested in the accepted answer on the question you're referring to is a valid approach. The other option is to stop generating the files when you've reached a stable point for your entities. Normally they shouldn't keep changing too much (since that will introduce challenges with migrations etc). And if the changes are small enough (like adding a new property etc) its easy to do this manually.
You could also have a look at Moogenerator which I know a lot of ppl who are happy with.
An answer to a question of mine on DB design suggested something called single table inheritance. I've done a bit of searching on that, but I can't seem to find that much clear information on it.
Basically what I seem to understand from it is that you have a big table with all the fields in it and also a type field - and then your ORM layer uses the type field to give you different object views. Is that correct?
More importantly, is single table inheritance an 'approved' database design technique? By that I mean is it 'sensible' to use it? Is it also safe to use it, or does it cause problems?
The other issue is how well this works in rails? I've found a few references to it from rails - but does it cause problems by doing things the non-conventional way?
Any help much appreciated.
Is it a good idea ? It depends. It breaks Normalization in that a table does not have a single purpose. What happens when you extend the base class for the nth time ? You will have to add columns to the table. Most modern DBs don't have a problem with that as you can modify the table but what about refactoring and removing a class. Now you have columns that don't have a purpose.
A rule of thumb - if most of design has been worked out, it's probably safe to use. If the design is changing frequently - you have other issues and you need to lock down your use cases/user requirements. (yes, not really XP friendly)
I don't know about the Rails effects.
STI is a way of dealing with a mismatch between object- and database-oriented thinking. It allows a reasonable representation of the information within the database and a different representation within the object model.
For example, I have an application where each of my products contains one or more fees, each calculated slightly differently. Within my object model I want to have subclasses of a Fee class, each of which knows how to calculate itself. I don't really want to have a table per fee type though: so I create Fee as the base class and fees as the table, which contains the union of all the fields needed across all the sub-types, plus a "type" column whose value corresponds to the name of the relevant sub-class. ActiveRecord handles the plumbing thereafter.
In short, Single Table Inheritance (STI) is a design pattern that allows a mapping of OOP inheritance relationships to the database. If you define any subclasses from your ActiveRecord model objects, then you should consider STI.
STI is (originally?) documented in Martin Fowler's 'Patterns of Enterprise Application Architecture' book, and is also described in DHH's canonical Rails book 'Agile Web Development with Rails' (section 18.4, I think.) I refer you to these books because they provide a much better explanation than I could hope to do in this space.
I strongly disagree with the sentiment expressed at www.matthewpaulmoore.com (linked by robintw in this thread), that STI is inherently a bad thing. This seems to be a somewhat naive view that discounts the usage of OOP inheritance. I have used STI to create some elegant solutions in Rails, but you can abuse any design pattern, I suppose.
Definitive reference. It allows a single table to store multiple objects that have a common base class.
Ruby on Rails uses a library called Active Record. This is a common Ruby framework that supports STI.
I can only speak from the (new) ADO Entity Framework perspective, which includes table-per-type (TPT) functionality.
Here is a good series of blog posts introducing the core concepts (using the Entity Framework) and there is an MSDN paper on it also here.
There also seems to be some guidance when using nHibernate for TPT, it's located here.
There's this link which explains table-per-type inheritance in SQL Server. This seems to have a pretty good summary and introduction to the concept.
I'm not sure what impact it would have on Rails.
I've just seen http://www.matthewpaulmoore.com/articles/1276-ruby-on-rails-code-quality-checklist#sti which suggests its a bad idea.
Generally I find it useful, but I've encountered some bugs
The example in that link may provide a useful picture of how you might use it.