map Deklaration. C++ technisch ok?

Hallo!

Ich bin auf der Suche nach einer geeigneten Datenstruktur für mein entstehendes Internationalisierungstool.
Prinzipiell soll es ähnlich wie das bekannte gettext ablaufen:
Es gibt die englischen Standard-Vorgabenachrichten, die MSGIDs und es kann keine, eine oder mehrere Übersetzungen für jede MSGIDs geben. Jede Sprache hat dabei eine eindeutige Identifikationsnummer (lang_id).

MSGID            lang_id    MSGSTR
"Hello world!"   1		 "Hallo Welt!"
                 2         "Hola mundo!"
                 3         "Ahoj svět!"
				... usw

Beim Suchen im Forum bin ich auf map gestossen und habe mir das hier zurechtgetippt:

map <string, map <int, string> > langfiles;

Gibts ne bessere Möglichkeit, oder ist es so machbar, bzw. steht mir Schiffbruch bevor?

Gruß,
c.

brauchst du wirklich ne map für die lang_id? tuts nicht auch ein vektor?

Warum machst du nicht

std::map<std::string,std::vector<string>> langfiles;

Grundsätzlich würde ich's so machen, aber die erste Map über die lang_id laufen lassen.

Da man aber die Sprache nur sehr selten auswählt (in der Regel ja wohl nur einmal bei jedem Start des Programms), würde ich bei einer konkreten Implementierung wohl auf die zweite Map verzichten. Etwa so:

std::string translate(const std::string &message) {

   static bool initialized = false;
   static std::map<std::string, std::string> messages;

   if(!initialized) {
      int lang_id getLanguage();
      initMessages(messages, lang_id);
      initialized = true;
   }
   return messages[message];
}

Und wahrscheinlich wäre das Ganze bei mir wohl auch ein Singleton.

Stefan.

Samsn schrieb:

Warum machst du nicht

std::map<std::string,std::vector<string>> langfiles;

diesem Beitrag deaktivier schrieb:

brauchst du wirklich ne map für die lang_id? tuts nicht auch ein vektor?

Angenommen ich will die Übersetzungen mit lang_id 5 und 14 von insgesamt 32 möglichen lang_ids ändern.
Ok, geht, wenn ich den Vector von Index 0 bis 31 mit NULL vorbelege und an Pos. 5 und 14 die Übersetzungen aufsuche. Sollte wohl keine allzugroße Speicherverschwendung sein.

Grautvornix schrieb:

Da man aber die Sprache nur sehr selten auswählt (in der Regel ja wohl nur einmal bei jedem Start des Programms), würde ich bei einer konkreten Implementierung wohl auf die zweite Map verzichten.

Stimmt, im Programmverlauf ja, da genügt eine Map.

Das ganze hätte ich noch etwas klarer beschreiben sollen: Das ganze muss ja auch verwaltet werden, d.h. die Übersetzungen können sich ändern, können gelöscht werden und es können neue hinzukommen.

datenstruktur creat0r schrieb:

Das ganze hätte ich noch etwas klarer beschreiben sollen: Das ganze muss ja auch verwaltet werden, d.h. die Übersetzungen können sich ändern, können gelöscht werden und es können neue hinzukommen.

Das verwirrt mich ein bischen. Befinden sich die Übersetzungen nicht letztlich in Dateien? Dann wäre es doch naheliegend, die Übersetzungen zu laden, wenn man sie braucht, ganz gleich, ob zur Bearbeitung oder zur Verwendung. Man hätte immer nur die Übersetzungen für eine einzige Sprache im Speicher.

Oder übersehe ich da was?

Stefan.

kimmi

Je nach Anzahl vorhandener Texte rate ich auch zu einer Lösung mit Dateien. Je nach Anzahl unterstützter Sprachen kann das eine ganze Menge Memory verbraten, auf den du zur Laufzeit so gut wie nie zurückgreifst. Wie oft wechselt der Anwender die Sprache.
Hinterlege dir die Texte doch z.B. in XML-Dateien, wobei der Name einer XML-Datei die LanguageId bzw. Sprache ist.

Gruß Kimmi

Anfangs wollte ich die Übersetzungen aller Sprachen in einer einzigen Datei speichern
(map <string, map <int, string>> langfiles),
aber das würde wohl doch unnötig kompliziert werden. Für jede Sprache eine separate Datei anzulegen, scheint mir doch die bessere Wahl zu sein.

DStefan

datenstruktur creat0r schrieb:

Anfangs wollte ich die Übersetzungen aller Sprachen in einer einzigen Datei speichern
(map <string, map <int, string>> langfiles),
aber das würde wohl doch unnötig kompliziert werden. Für jede Sprache eine separate Datei anzulegen, scheint mir doch die bessere Wahl zu sein.

Naja... Die Datei-Struktur muss sich ja nicht unbedingt in den Datenstrukturen des Programms widerspiegeln. Selbst wenn es nur eine Datei für alle Sprachen wäre (was ich bevorzugen würde), könnte man doch aus der Datei nur eine Sprache lesen. Es hängt wohl vom Dateiformat ab, ob dies kompliziert wäre.

Stefan.

LordJaxom

Grautvornix schrieb:

Da man aber die Sprache nur sehr selten auswählt (in der Regel ja wohl nur einmal bei jedem Start des Programms), würde ich bei einer konkreten Implementierung wohl auf die zweite Map verzichten.

Das ist ein verfrühter Schluß, der schon bei gettext dazu geführt hat, dass es nicht kontextsensitiv ist. Was machst Du denn z.B. in einer (C++)-Webanwendung, wo der Client entscheidet, welche Sprache er sprechen möchte?

DStefan schrieb:

Naja... Die Datei-Struktur muss sich ja nicht unbedingt in den Datenstrukturen des Programms widerspiegeln. Selbst wenn es nur eine Datei für alle Sprachen wäre (was ich bevorzugen würde), könnte man doch aus der Datei nur eine Sprache lesen. Es hängt wohl vom Dateiformat ab, ob dies kompliziert wäre.
Stefan.

Dann müsste aber auch jeder User die Datei mit allen Übersetzungen vorrätig haben. Ok, das Programm ist klein, es gibt nicht viele Nachrichtenstrings, wäre also auch vertretbar.

datenstruktur creat0r schrieb:

Dann müsste aber auch jeder User die Datei mit allen Übersetzungen vorrätig haben. Ok, das Programm ist klein, es gibt nicht viele Nachrichtenstrings, wäre also auch vertretbar.

Der User muss aber auch das Programm vorrätig haben
Installier doch einfach die Datei mit! Wenn sie vom nicht auffindbar ist, dann muss halt der Anwender mit den Strings aus dem Quelltext zurecht kommen

Und wenn du Angs hast dass die Datei viel Speicher braucht, binde doch zip-Kompression ein. (libzip)

kimmi

Noch ein Vorteil, wenn du je Sprache ein File nimmst: Wenn du es geschickt anstellst, kannst du Sprachen nachinstallieren :-). Nur ein Hinweis meinerseits, falls du Lust auf Featurites hast ;-).

Gruß Kimmi