Obsługiwane formaty plików

Weblate supports a wide range of translation formats. Each format is slightly different and provides a different set of capabilities.

Podpowiedź

When choosing a file format for your application, it’s better to stick some well established format in the toolkit/platform you use. This way your translators can additionally use whatever tools they are used to, and will more likely contribute to your project.

• Android string resources
• Ciągi Apple iOS
• Pliki metadanych sklepu z aplikacjami
• Plik ARB
• Pliki CSV
• Pliki DTD
• Excel Open XML
• Jednolity plik XML
• Format Fluent
• GNU gettext
• go-i18n pliki JSON
• gotext JSON files
• Właściwości GWT
• Pliki HTML
• i18next JSON files
• Format IDML
• Tłumaczenia INI
• Tłumaczenia Inno Setup INI
• Właściwości Java
• Tłumaczenia Joomli
• Plik JSON
• Ciągi znaków Laravel PHP
• Markdown files
• Pliki lang dla mi18n
• Format OpenDocument
• Ciągi PHP
• Qt Linguist .ts
• Pliki ResourceDictionary
• RESX .NET resource files
• Pliki Ruby YAML
• Format stringsdict
• Pliki napisów
• Format TermBase eXchange
• Pliki tekstowe
• WebExtension JSON
• Pliki RC systemu Windows
• XLIFF
• Pliki YAML

Zobacz także

Translation Related File Formats

Automatyczne wykrywanie

Weblate tries to detect file format during Dodawanie projektów i komponentów tłumaczeniowych. The detection might be wrong for different variants of the same serialization format (JSON, YAML, properties) or file encoding, so please verify that Format pliku is correct before creating the component.

Możliwe typy tłumaczeń

Capabilities of all supported formats

Format	Lingualność [1]	Liczba mnoga [2]	Opisy [3]	Kontekst [4]	Lokalizacja [5]	Flagi [8]	Dodatkowe stany [6]
GNU gettext	dwujęzyczny	tak	tak	tak	tak	Tak [9]	wymaga edycji
Jednojęzyczny gettext	mono	tak	tak	tak	tak	Tak [9]	wymaga edycji
XLIFF	oba	tak	tak	tak	tak	tak	wymaga edycji, zatwierdzono
Właściwości Java	oba	nie	tak	nie	nie	nie
Pliki lang dla mi18n	mono	nie	tak	nie	nie	nie
Właściwości GWT	mono	tak	tak	nie	nie	nie
Tłumaczenia Joomli	mono	nie	tak	nie	tak	nie
Qt Linguist .ts	oba	tak	tak	nie	tak	tak	wymaga edycji
Android string resources	mono	tak	tak [7]	nie	nie	tak
Ciągi Apple iOS	oba	nie	tak	nie	nie	nie
Ciągi PHP	mono	nie [10]	tak	nie	nie	nie
Plik JSON	mono	nie	nie	nie	nie	nie
i18next JSON files	mono	tak	nie	nie	nie	nie
go-i18n pliki JSON	mono	tak	tak	nie	nie	nie
gotext JSON files	mono	tak	tak	nie	tak	nie
Plik ARB	mono	tak	tak	nie	nie	nie
WebExtension JSON	mono	tak	tak	nie	nie	nie
RESX .NET resource files	mono	nie	tak	nie	nie	tak
Pliki ResourceDictionary	mono	nie	nie	nie	nie	tak
Pliki CSV	oba	nie	tak	tak	tak	nie	wymaga edycji
Pliki YAML	mono	nie	nie	nie	nie	nie
Pliki Ruby YAML	mono	tak	nie	nie	nie	nie
Pliki DTD	mono	nie	nie	nie	nie	nie
Jednolity plik XML	mono	nie	nie	nie	nie	tak
Pliki RC systemu Windows	mono	nie	tak	nie	nie	nie
Excel Open XML	mono	nie	tak	tak	tak	nie	wymaga edycji
Pliki metadanych sklepu z aplikacjami	mono	nie	nie	nie	nie	nie
Pliki napisów	mono	nie	nie	nie	tak	nie
Pliki HTML	mono	nie	nie	nie	nie	nie
Markdown files	mono	nie	nie	nie	nie	nie
Format OpenDocument	mono	nie	nie	nie	nie	nie
Format IDML	mono	nie	nie	nie	nie	nie
Tłumaczenia INI	mono	nie	nie	nie	nie	nie
Tłumaczenia Inno Setup INI	mono	nie	nie	nie	nie	nie
Format TermBase eXchange	dwujęzyczny	nie	tak	nie	nie	tak
Pliki tekstowe	mono	nie	nie	nie	nie	nie
Format stringsdict	mono	tak	nie	nie	nie	nie
Format Fluent	mono	nie [11]	tak	nie	nie	nie

[1]

Zobacz Formaty dwujęzyczne i jednojęzyczne

[2]

See Pluralized strings

[3]

See Opis ciągu źródłowego

[4]

See Kontekst

[5]

See Położenie ciągu źródłowego

[6]

See String states

[7]

XML comment placed before the <string> element, parsed as a source string description.

[8]

See Flagi tłumaczeń.

[9] (1,2)

The gettext type comments are used as flags.

[10]

The plurals are supported only for Laravel which uses in string syntax to define them, see Localization in Laravel.

[11]

Plurals are handled in the syntax of the strings and not exposed as plurals in Weblate.

Formaty dwujęzyczne i jednojęzyczne

Both monolingual and bilingual formats are supported. Bilingual formats store two languages in single file—source and translation (typical examples are GNU gettext, XLIFF or Ciągi Apple iOS). On the other side, monolingual formats identify the string by ID, and each language file contains only the mapping of those to any given language (typically Android string resources). Some file formats are used in both variants, see the detailed description below.

For correct use of monolingual files, Weblate requires access to a file containing complete list of strings to translate with their source—this file is called Jednojęzyczny bazowy plik języka within Weblate, though the naming might vary in your paradigm.

Additionally this workflow can be extended by utilizing Plik języka pośredniego to include strings provided by developers, but not to be used as is in the final strings.

String states

Many file formats only differentiate „Untranslated” and „Translated” strings. With some formats it is possible to store more fine-grained state information, such as „Needs editing” or „Approved”.

Opis ciągu źródłowego

Source string descriptions can be used to pass additional info about the string to translate.

Several formats have native support for providing additional info to translators (for example XLIFF, GNU gettext, WebExtension JSON, Pliki CSV, Excel Open XML, Qt Linguist .ts, go-i18n pliki JSON, gotext JSON files, Plik ARB, RESX .NET resource files). Many other formats extract closest comment as source string description.

Objaśnienie

The Objaśnienie on strings can be stored and parsed from a few file formats.

Currently supported only in Format TermBase eXchange.

Położenie ciągu źródłowego

Location of a string in source code might help proficient translators figure out how the string is used.

This information is typically available in bilingual formats where strings are extracted from the source code using tools. For example GNU gettext and Qt Linguist .ts.

Flagi tłumaczeń

Translation flags allow customizing Weblate behavior. Some formats support defining those in the translation file (you can always define them in the Weblate interface, see Dostosowywanie zachowania za pomocą flag).

This feature is modelled on flags in GNU gettext.

Additionally, for all XML based format, the flags are extracted from the non-standard attribute weblate-flags. Additionally max-length:N is supported through the maxwidth attribute as defined in the XLIFF standard, see Określanie flag tłumaczenia.

Zobacz także

Dostosowywanie zachowania za pomocą flag, PO files documentation

Kontekst

Context is used to differentiate identical strings in a bilingual format used in different scopes (for example Sun can be used as an abbreviated name of the day „Sunday” or as the name of our closest star).

For monolingual formats the string identifier (often called key) can serve the same purpose and additional context is not necessary.

Pluralized strings

Plurals are necessary to properly localize strings with variable count. The rules depend on a target language and many formats follow CLDR specification for that.

Podpowiedź

Pluralizing strings need proper support from the application framework as well. Choose native format of your platform such as GNU gettext, Android string resources or Format stringsdict.

Ciągi tylko do odczytu

Read-only strings from translation files will be included, but can not be edited in Weblate. This feature is natively supported by few formats (XLIFF and Android string resources), but can be emulated in others by adding a read-only flag, see Dostosowywanie zachowania za pomocą flag.

Obsługa innych formatów

Most formats supported by translate-toolkit which support serializing can be easily supported, but they did not (yet) receive any testing. In most cases some thin layer is needed in Weblate to hide differences in behavior of different translate-toolkit storages.

To add support for a new format, the preferred approach is to first implement support for it in the translate-toolkit.

Zobacz także

Translation Related File Formats