fuel / docs

Fuel PHP Framework - Fuel v1.x documentation
http://fuelphp.com/docs
Other
166 stars 233 forks source link

(Classes) Lang - DB-schema improvements and a note about serialized data in the table #667

Closed vladimir-light closed 9 years ago

vladimir-light commented 10 years ago

I do not know if it's the right topic for that, but the shown DB-schema for \Lang setup is kind of confusing. Indeen, the whole part about DB isn't explained well (IMHO)

The usage of DB as a "lang-file" gives an the ability to store all translation-line for all (used) languages in one place, right?

If so, making identifier column as only one primary key — isn't great, since same identifier for different languages would cause an Integrity constraint violation

For instance, I'd like to put all general-ui-element tranlsations into a group called general and make it available in three different languages: en:english, de:german and ru:russian. As I said before, with shown db schema it is not possible

It woud be also nice to somewhere see a note about data serialization and the idea of saving whole lang-file content as a single record. I assume, in most cases (at the stage of learning fuel) people start using lang-files (*.php) but then realize they would rather use DB as their storage-type. At that point most of them copy and paste CREATE_TABLE statement and try to INSERT single records as a single translation-line, without knownig, that it will not work

A note about hash column and what it stands for — would be also nice

WanWizard commented 10 years ago

You're welcome to clone the repo, make the changes that makes it better, and send in a pull request.

WanWizard commented 9 years ago

I've looked at this again, but I don't get the problem, I think you haven't read it properly.

The DB schema in the docs defines a table with a compound primary key, containing both Identifier and Language, so it is perfectly in line with what you want, there will not be an integrity violation. It will work perfectly.

The hash column is only used internally, and has no user value. It is used to force a database update on some platforms to avoid issues where affected_rows is zero, but the update went fine.