Lokalizační soubory (Strings)

Lokalizační soubory jsou textové soubory, které lze otevřít a upravit v textovém editoru, jako je Poznámkový blok nebo TextEdit, nebo v jednom z mnoha rozšířených textových Nástroje používaných programátory. Tyto soubory obecně následují princip klíč-hodnota. To znamená, že obsahují seznam textových úryvků (Strings), které jsou spojeny s unikátními ID (klíče). Každý řetězec je tedy hodnota klíče (Tento jednoduchý příklad je formát lokalizačních souborů používaných v programování v jazyce Java.):

Vytvořit lokalizačních souborů

Lokalizační soubory jsou prosté textové soubory s jednoduchou strukturou. Mohou být vytvořeny ručně, ale obvykle jsou automaticky generovány internacionalizačními nástroji nebo skripty, které jsou dostupné pro různá vývojová prostředí. Automatické Vytvořit lokalizačních souborů zajišťuje, že struktury souborů jsou platné.

Pro Vytvořit lokalizačního souboru jsou všechny části zobrazitelného textu v souborech kódu nahrazeny unikátními klíči. Textové Strings jsou poté přidány do lokalizačního souboru spolu se svými klíči.

použít lokalizačních souborů

Místo skutečných textových Strings nyní kód obsahuje pouze klíče. Když software generuje zobrazení pro uživatel, tyto klíče se použijí k vyhledání přidružených Strings v lokalizačním souboru.

Pokud je aplikace nastavit tak, aby byla používána v angličtině a španělštině, veškerý anglický text může být uchováván v souboru s názvem English.txt a je výchozím umístěním textu. Pokud uživatel nevybere jazyk, veškerý text bude pro generování jakéhokoli zobrazení načten z tohoto souboru. Pokud uživatel vybere španělštinu, software je přesměrován na Spanish.txt. Se systémem, jako je tento, lze používat mnoho jazyků.

Výhodou je, že volba jazyka pro zobrazení neovlivňuje kód. Pokud software potřebuje zobrazit přihlašovací tlačítko, může vyžadovat řetězec spojený s klíčem login_button a potřebuje pouze vědět, ve kterém souboru má hledat, aby získal příslušný řetězec pro daný jazyk.

Správa řetězců

Jako platforma pro překlady založená na klíčích podporuje Phrase mnoho různých typů souborů zdrojů. Po nahrání souborů jsou extrahovány klíče a jejich přidružené hodnoty řetězců. Klíče a řetězce jsou poté předloženy překladateli ve standardizovaném formátu. Překladatelé se soustředí na svůj úkol, aniž by se museli starat o přesný formát lokalizačního souboru. Mohou zkontrolovat klíče, protože klíč sám o sobě může poskytnout zásadní kontext a vést je ke správné volbě slov.

Když jsou všechny Strings přeloženy, soubory se stáhnou. V tomto procesu se vytvoří potřebný formát lokalizačního souboru, který odpovídá původnímu zdrojovému souboru.

Formáty souborů zdrojů

Podporovány jsou čtyři široké typy zdrojů, které jsou v podstatě založeny na textu a lze je otevřít a zkontrolovat v textovém editoru.

Tabulky

Soubory .XLSX a .CSV jsou podporovány. Tyto formáty jsou pro účely lokalizace ekvivalentní a obsahují řádky párů klíč-hodnota. Klíče jsou v jednom řádku, zatímco odpovídající hodnoty jsou v sousedním řádku. Který přesný sloupec se použije pro jaký účel, závisí na aplikaci a lokalizátor musí nakonfigurovat Phrase tak, aby sloupce interpretoval správně. Soubory Zendesk .CSV mají pevnou strukturu, takže tento typ souboru nevyžaduje další úpravy:

"Title","Default jazyk","Default text","English text","Variant stav"
"simple_key","němčina","Einfacher Schlüssel.","Jednoduchý klíč.","Aktuální"

XML

XML je formát, který nabízí metainformace ve formě <tagů>. Struktura tagů se používá k určení, kde se nacházejí klíče a jejich odpovídající hodnoty, jak je zde ukázáno na souboru Android XML:

 <string name="simple_key">Just a  key with a message.</string>

Dva standardní formáty překladu XML jsou .TMX a .XLIFF. Tyto neobsahují pouze klíče a hodnoty v jednom jazyce, ale také přiřazují páry hodnot ze zdrojového jazyka k odpovídajícím hodnotám z cílového jazyka. Takové soubory jsou obvykle dvojjazyčné, jak ukazuje tato překladová jednotka v souboru Symfony Xliff:

<trans-unit id="simple_key" resname="simple_key">
 <source xml:lang="de-DE">Nur ein einfacher Schlüssel mit einer einfachen Nachricht.</source
<target xml:lang="en-GB">Just a simple key with a simple message.</target>
</trans-unit>

Programy QT používají soubory prostředků se strukturou, která je velmi podobná těmto standardizovaným formátům, ale z historických důvodů mají odlišné rozvržení.

Prosté seznamy klíč-hodnota

Existují soubory prostředků, které obsahují pouze jednoduché seznamy klíčů a hodnot, jak ukazuje tento úryvek z Ruby on Rails YAML:

simple_key: Just a simple key with a simple message.

Mnoho různých programovacích jazyků nebo platforem používá takové formáty s Méně závažné rozdíly v rozvržení.

Protože se jedná o jednojazyčné soubory, lokalizační program musí udržovat paralelní verze takových souborů – jednu pro zdrojový jazyk a ostatní pro cílové jazyky.

Gettext vytváří soubory klíč-hodnota obsahující doplňující informace, jako jsou popisné komentáře nebo varianty množného čísla:

# Toto je úžasný popis pro tento klíč!
msgid "key_with_description"
msgid_plural """
msgstr[0] \"Podívejte se na to!" This key has a description! (At least in some formats)"
msgstr[1] \"Podívejte se na to!" Tento klíč má %s popisů! (At least in some formats)"

Existují konkurenční formáty s podobnou funkčností a rozvržením, které se liší relativně Méně závažné způsoby.

Asociativní pole

Zatímco jiné formáty vyžadují Vlastní kód (parsery) pro jejich čtení, některé formáty jsou pro vývojáře a lokalizátory snazší. Formáty založené na .JSON (JavaScript) a .PHP polích lze číst a mapovat přímo do běžných kódových struktur (polí), se kterými se snadno manipuluje. Pole mohou být složitá a různé aplikace generují Vlastní struktury polí.

Například go-i18n JSON odkazuje na klíče jako ID:

{
    "id": "simple_key",
    "translation": "simple key, simple message, so simple."
},

Angular používá samotné klíče jako klíče ve svých polích:

\"simple_key\": \"I am a simple key with a simple message.\"."

Protože existují tyto Méně závažné, ale zásadní rozdíly, jsou podporovány široce používané struktury .JSON a .PHP Array.