search

Litotex / Litotex-0.8

litotex.net
Other
18 stars 5 forks source link

L10n system #4

Open secondtruth opened 12 years ago

secondtruth commented 12 years ago

Use a database-based L10n system like in Drupal.

See https://github.com/iceflame-net/Webwork/blob/master/includes/classes/Lang.class.php

jnugh commented 12 years ago

Why should that be implemented? The file system does it quite well. I would import a commit if you migrate the current Code while maintaining backwards compatibility. I will not work on this thought.

secondtruth commented 12 years ago

With this system, translations are easier to maintain from the ACP.

jnugh commented 12 years ago

Why are files more complicated? As I said, if you want to change this feel free, but it must be backwards compatible. There are more important things to do right now.

secondtruth commented 12 years ago

Why are files more complicated?

Files are not more complicated, but with the database it is easier, because all strings and their translations are at one place (1 table). So you only need to SELECT, INSERT or UPDATE. Additionally, coders don't need to work on language files anymore: They can write directly, what they want to "say".

As I said, if you want to change this feel free, but it must be backwards compatible.

I will do it, later. But backwards compatible to what?

There are more important things to do right now.

OK, I agree. :)

jnugh commented 12 years ago

Backwards compatibility to the current system, or the best thing would be an automated import. I think this would be best to migrate current packages.

SiSoSnooP commented 12 years ago

it is unnecessary to always invite all the strings from the db. I think file system is ok.

secondtruth commented 12 years ago

Caching!

SiSoSnooP commented 12 years ago

Caching ? Also wenn ich das richtig verstanden habe, soll erst alles von der Datenbank geladen werden, um es dann in ein CachFile zu speichern, von welchem wiederum die Sprachvariablen gelesen werden?

Haben wir doch auch so, nur das wir uns den Zugriff auf die Datenbank sparen. Von der Platte lesen wir auch :)

Abgesehen davon I18n ist weit aus mehr als nur der Umgang mit Sprachvariablen. Die von dir genannte Klasse unterstützt keine wirkliche Internationalisierung. Denn hierbei sollten Währungen, Datumsformate Maßangaben etc ebenfalls umgerechnet werden.

Wir unterstützen, in der jetzigen Version lediglich Lokalisierung, nicht Internationalisierung.

secondtruth commented 12 years ago

@SiSoSnooP Also wenn ich das richtig verstanden habe, soll erst alles von der Datenbank geladen werden, um es dann in ein CachFile zu speichern, von welchem wiederum die Sprachvariablen gelesen werden?

Ja, so ist es (So wie in 0.7 die Settings-Files erstellt werden). Nur arbeiten wir nicht mehr mit "Variablen", sondern mit dem Text selbst und dessen Übersetzung.

@SiSoSnooP Haben wir doch auch so, nur das wir uns den Zugriff auf die Datenbank sparen. Von der Platte lesen wir auch :)

In der Datenbank kann man die Texte aber besser verwalten, da du nur SELECT, INSERT oder UPDATE machen musst. Außerdem kannst du in der Datenbank viel besser nach noch nicht übersetzten Texten suchen.

@SiSoSnooP I18n ist weit aus mehr als nur der Umgang mit Sprachvariablen. Die von dir genannte Klasse unterstützt keine wirkliche Internationalisierung. Denn hierbei sollten Währungen, Datumsformate Maßangaben etc ebenfalls umgerechnet werden.

Das kann ja später noch dazukommen, aber im Moment brauchen wir es nicht, das stimmt.

SiSoSnooP commented 12 years ago

ich würde es gern für die nächste version aufheben. Denn momentan haben wir noch vieeele andere baustellen und sorgen :)