Konvertieren drei Buchstaben bestehenden Sprachcode zu Sprachkennung (LANGID)

Question

Gibt es irgendeine Art und Weise in der Win32-API einen drei Buchstaben bestehenden Sprachcode zu konvertieren, wie GetLocaleInfo() mit LOCALE_SABBREVLANGNAME angegeben, um ein entsprechenden LANGID oder LCID zurückgegeben? Das heißt, gehen Sie "umgekehrt" zu dem, was normalerweise tut?

Was ich versuche zu tun, zu analysieren, welche Art von Sprache einer Ressource DLL verwendet, und so weit, ohne etwas über die DLL zu berühren, von dem DLL-Namen mit einem Format gehen nameLNG.dll, wo LNG ist ein drei Buchstaben-Code, scheint die einfachste Methode zu sein, vorausgesetzt, eine solche Funktion existiert.

Wenn dies nicht einfach zu tun ist, denke ich, dass Plan B unseren Sprach-DLLs eine Versionsinfo-Ressource geben soll, dort ihre jeweiligen Kulturen angeben und später in der Anwendung lesen, welche Kulturen sie verwenden.

Answer 1

Leider gibt es keine direkte Win32-API, die Ihnen eine LANGID mit einer 3-Buchstaben-Abkürzung gibt.

Es sieht aus wie CLanguageSupport ist dein Freund today :-) Es implementiert bereits Ihren Plan B, um die LANGID basierend auf dem Inhalt der Versionsinfo-Ressource nachzuschlagen.

Das Stück Code, den Sie suchen ist int die Funktion

LANGID CLanguageSupport::GetLangIdFromFile(LPCTSTR pszFilename) 

Natürlich ist der Nachteil ist, dass Sie eine Diskrepanz zwischen der Versionsinformation und dem DLL-Namen haben. Aber Sie würden es sehr schnell während der Tests erfassen. Und wenn Sie ein Tool wie appTranslator die DLLs für Sie erstellen lassen, sind Sie sicher auf der sicheren Seite.

Answer 2

Sie können die installierten Ländereinstellungen mit EnumSystemLocales() auflisten und die Karte selbst erstellen. Ich mache das während der Anwendungsinitialisierung in einem Dienst, den ich vor einiger Zeit geschrieben habe, und es hat bisher gut funktioniert.

Ich würde in diesem Fall empfehlen, Plan B zu verwenden. Ich verzichte normalerweise auf die Codierung von Dateien in den Dateinamen. Wenn aus anderen Gründen die 3-stellige ISO-639 Variante nicht perfekt ist, wenn Sie nicht genau angeben, welche Variante Sie verwenden - ISO-639-2/B, ISO-639-2/T oder ISO-639-3.

Wenn Sie länderspezifische Varianten angeben müssen, sollten Sie einen Blick auf RFC3066 werfen. Grundsätzlich müssen Sie die Sprache und den Ländercode und in einigen Fällen auch den Ländercode angeben. In jedem Fall kapselt die LCID all diese Güte ein.

Die eine Sache, die ich nicht ganz sicher bin, ist, ob die LangID in der Ressource Informationen eine vollständige LCID ist oder nicht. Die Codes, die in der VERSIONINFO Referenz aufgeführt sind, sind LCIDs, also würde ich versuchen, eine LCID in dem VERSIONINFO-Header zu verwenden. Wenn nicht, können Sie die Informationen immer als Zeichenfolge in den Zeichenfolgenblock aufnehmen.

Answer 3

können Sie die LangID erhalten durch GetLocaleInfo() mit LOCAL_RETURN_NUMBER|LOCALE_ILANGUAGE für die LCType Parameter aufrufen, wie Sie LOCALE_SABBREVLANGNAME den aus drei Buchstaben bestehenden ISO-Code zu erhalten, übergeben. Durch Übergeben derselben IDCID an diese Funktion können Sie die entsprechende LangID mit dem ISO-Code speichern.

Beachten Sie, dass MSDN LOCALE_ILANGUAGE sagt sollte nicht zugunsten LOCALE_SLANG auf Vista und höher verwendet werden, aber ich glaube, dass der Kommentar nicht für die Verwendung von LOCALE_ILANGUAGE mit LOCALE_RETURN_NUMBER gilt.

Wenn sich Ihr Projekt weiterentwickelt, können Sie mehrere lokalisierte Dateien für jede Sprache generieren. Aus diesem Grund würde ich vorschlagen, dass Sie Ihre lokalisierten Dateien in Unterverzeichnissen speichern, die nach der Sprache benannt sind. Microsoft hat Verzeichnisse verwendet, die nach den LangIDs benannt sind, z. B. "1033" als das englische Ressourcenverzeichnis. Ich denke, es wäre freundlicher, den Drei-Buchstaben-Code zu verwenden, wie "ENU \ name.dll". In jedem Fall sind Unterverzeichnisse eine einfache Lösung und werden Ihren Buildprozess hoffentlich nicht so sehr verkomplizieren, wie den Zieldateinamen zu ändern.