Ich habe ein ziemlich kompliziertes Projekt, bestehend aus mehreren großen lokalisierten Teilprojekten.
Die meisten meiner Unterprojekte sind durch eine einzelne Datei Localizable.strings lokalisiert. Diese Datei wird in ein SubProjectName.bundle -Ziel kopiert, das in Verbindung mit einer statischen Bibliothek SubProjectName.a im Hauptprojekt verwendet wird. Das funktioniert gut.
Eines meiner Unterprojekte enthält jedoch viele lokalisierte .strings-Dateien. Dieses Projekt kann keine Zeichenfolgen in einer anderen Sprache als Englisch lesen, unabhängig davon, wie das Gerät (oder der Simulator) konfiguriert ist.
Diese Codezeile gibt beispielsweise immer die englische Zeichenfolge zurück:
%Vor% Dabei entspricht MyTable einer MyTable.strings-Datei, die in mehreren Sprachen lokalisiert ist. Wenn ich in das .app-Paket gucke, sind alle Lokalisierungen vorhanden und befinden sich innerhalb der "MyBundle.bundle" -Ressource innerhalb der App.
Der folgende Code findet jedoch die Übersetzungen für eine gegebene Zeichenfolge in allen Lokalisierungen korrekt:
%Vor% Wenn also das Paket der eigentliche Ordner MyBundle.bundle/<LanguageCode>.lproj ist, funktioniert die Suche nach Zeichenfolgen. Aber offensichtlich vereitelt dies den Zweck der automatischen Suche von iOS.
(Beachten Sie, dass [NSBundle myResourcesBundle] oben einfach eine statische Komfortmethode ist, um mein benutzerdefiniertes Bundle für das Unterprojekt abzurufen).
-
Bearbeiten : Ich experimentiere noch etwas damit, und wenn ich den Ordner en.lproj aus dem Paket meines Unterprojekts lösche, wird das Gebietsschema des Geräts oder Simulators korrekt verwendet.
Zum Beispiel habe ich:
%Vor% Wenn ich den Simulator (oder das Gerät) auf Chinesisch vereinfacht einstelle, werden Strings in en.lproj angezeigt, obwohl das Gebietsschema zh-Hans lautet. Wenn ich den Ordner en.lproj lösche und die App neu starte, verwendet er korrekt die zh-Hans-Lokalisierung.
Ich habe jetzt eine hacky Lösung, aber würde mich freuen, wenn jemand eine bessere Antwort hat (oder eine Erklärung dafür, warum das obige nicht funktioniert).
Ich habe meine NSBundle-Kategorie um eine bevorzugte Sprachressource erweitert:
Kopfzeile
%Vor%Implementierung
%Vor%Ich habe dann ein einfaches Makro, um meine lokalisierten Strings zu bekommen:
%Vor% Diese Lösung ruft einfach den bevorzugten Sprachcode von NSLocale ab und prüft dann, ob ein Paket für diese Sprache existiert. Wenn nicht, greift es auf das Hauptressourcenbündel zurück (vielleicht sollte es die NSLocale preferredLanguage-Indizes durchlaufen, um zu prüfen, ob ein Bündel existiert? Weiß jemand das?)
Ich konnte das Problem reproduzieren und beheben, obwohl die Lösung impliziert, dass es einen Fehler in NSBundle gibt.
Ich habe es mit der folgenden Bündelstruktur reproduziert:
%Vor%und code:
%Vor%Wenn das Gebietsschema auf fr_FR gesetzt ist (d. h. Französisch), hat das Bündel den String aus der Tabelle der englischen Zeichenfolgen ausgewählt - selbst der String "kann ihn nicht finden" erscheint nicht.
Ohne den Code zu ändern, konnte ich stattdessen die französische Zeichenfolge mit der folgenden Struktur für das Paket abrufen:
%Vor%Es sieht so aus, als ob NSBundle immer noch die alte Mac OS X-Bundle-Struktur erwartet, anstatt das, was iOS verwenden soll. Eine einfache Änderung der Bündelstruktur sollte also das Problem lösen ...
Um hinzuzufügen, was David Doyle gesagt hat.
Stellen Sie sicher, dass Sie die verfügbaren Sprachen im Infobereich Ihres Projekts sowohl im Paket als auch in der Anwendung selbst festlegen. Wenn Sie beispielsweise Französisch und Englisch in Ihrer App unterstützen, stellen Sie sicher, dass sowohl Ihr Bundle als auch Ihre App die französischen und englischen Sprachen in den verfügbaren Lokalisierungen für Ihre Projekte enthalten.
Ihre Frage ist nicht klar, aber ich benutze dieses Makro, um mehrere lokalisierte Zeichenketten zu verwenden:
%Vor%oder Sie können versuchen
%Vor% Dies überprüft zunächst Localizable.strings . Wenn der Schlüssel nicht existiert, gibt er den Schlüssel selbst zurück, prüft dann und verwendet MyTable.strings . Natürlich sollten Sie Ihren Schlüssel mit einem Präfix benennen. z.B. "KYName" = "Name"; .
Wenn Sie möchten, können Sie DIESE Frage, die ich schon einmal gestellt habe. ;)
Ich habe eine andere Lösung.
%Vor%also zum Beispiel, wenn wir einen Schlüssel "Titel"="Manager" finden; in Localizable.strings (fr) und wenn nicht, dann ist das Ergebnis für den Schlüssel "title" genau wie der Schlüssel.
In diesem Fall können wir den Schlüssel "title" in localizable.string (en) finden, aber wenn wir in (fr) finden können, können wir ihn einfach benutzen.
Tags und Links ios localization uikit nslocalizedstring nsbundle