Localization file formats

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

Consejo

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.

Detección automática

Weblate tries to detect file format during Añadir proyectos y componentes de traducción. The detection might be wrong for different variants of the same serialization format (JSON, YAML, properties) or file encoding, so please verify that Formato de archivo is correct before creating the component.

Translation types capabilities

Capacidades de todos los formatos compatibles

Formato

Linguality [1]

Plurales [2]

Descripciones [3]

Contexto [4]

Lugar [5]

Flags [8]

Estados adicionales [6]

GNU gettext PO (Portable Object)

bilingual

yes

yes

yes

yes

yes [9]

needs editing

gettext monolingüe

mono

yes

yes

yes

yes

yes [9]

needs editing

XLIFF 1.1 and 1.2

both

yes

yes

yes

yes

yes

needs editing, approved

Propiedades de Java

both

no

yes

no

no

no

draggable/i18n lang files

mono

no

yes

no

no

no

Propiedades GWT

mono

yes

yes

no

no

no

Traducciones para Joomla

mono

no

yes

no

yes

no

.ts de Qt Linguist

both

yes

yes

no

yes

yes

needs editing

Recursos de cadenas de Android

mono

yes

yes [7]

no

no

yes

Cadenas de iOS de Apple

both

no

yes

no

no

no

Cadenas de PHP

mono

no [10]

yes

no

no

no

Archivos JSON

mono

no

no

no

no

no

Archivos JSON i18next

mono

yes

no

no

no

no

Archivos JSON de go-i18n

mono

yes

yes

no

no

no

Archivos JSON de texto gotext

mono

yes

yes

no

yes

no

Archivo ARB

mono

yes

yes

no

no

no

JSON para WebExtension

mono

yes

yes

no

no

no

Archivos de recursos .NET (RESX, RESW)

mono

no

yes

no

no

yes

Archivos ResourceDictionary

mono

no

no

no

no

yes

Archivos CSV

both

no

yes

yes

yes

no

needs editing

Archivos YAML

mono

no

no

no

no

no

Archivos YAML de Ruby

mono

yes

no

no

no

no

Archivos DTD

mono

no

no

no

no

no

Archivos XML sin formato

mono

no

no

no

no

yes

Archivos RC de Windows

mono

no

yes

no

no

no

Open XML de Excel

mono

no

yes

yes

yes

no

needs editing

Archivos de metadatos de tiendas de aplicaciones

mono

no

no

no

no

no

Archivos de subtítulos

mono

no

no

no

yes

no

Archivos HTML

mono

no

no

no

no

no

Archivos Markdown

mono

no

no

no

no

no

Formato OpenDocument

mono

no

no

no

no

no

Formato IDML

mono

no

no

no

no

no

Traducciones en INI

mono

no

no

no

no

no

Traducciones INI de Inno Setup

mono

no

no

no

no

no

Formato TermBase eXchange

bilingual

no

yes

yes

no

yes

Archivos de texto

mono

no

no

no

no

no

Formato Stringsdict

mono

yes

no

no

no

no

Formato fluido

mono

no [11]

yes

no

no

no

Formatos bilingües y monolingües

Both monolingual and bilingual formats are supported. Bilingual formats store two languages in single file—source and translation (typical examples are GNU gettext PO (Portable Object), XLIFF 1.1 and 1.2 or Cadenas de iOS de Apple). 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 Recursos de cadenas de Android). 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 Archivo de base monolingüe within Weblate, though the naming might vary in your paradigm.

Additionally this workflow can be extended by utilizing Archivo de idioma intermediario 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».

Descripción de cadena de origen

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 1.1 and 1.2, GNU gettext PO (Portable Object), JSON para WebExtension, Archivos CSV, Open XML de Excel, .ts de Qt Linguist, Archivos JSON de go-i18n, Archivos JSON de texto gotext, Archivo ARB, Archivos de recursos .NET (RESX, RESW)). Many other formats extract closest comment as source string description.

Explicación

The Explicación on strings can be stored and parsed from a few file formats.

Currently supported only in Formato TermBase eXchange.

Lugar de cadena origen

El lugar de una cadena dentro de código fuente podría ayudar a los traductores avezados a entender de qué manera una determinada cadena se utilizará.

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

Indicadores de traducción

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 Personalizar el comportamiento mediante indicadores).

This feature is modelled on flags in GNU gettext PO (Portable Object).

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 Especificar indicadores de traducción.

Contexto

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.

Consejo

Pluralizing strings need proper support from the application framework as well. Choose native format of your platform such as GNU gettext PO (Portable Object), Recursos de cadenas de Android or Formato Stringsdict.

Cadenas de solo lectura

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 1.1 and 1.2 and Recursos de cadenas de Android), but can be emulated in others by adding a read-only flag, see Personalizar el comportamiento mediante indicadores.

Supporting other formats

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

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

Parámetros del formato de archivo

File format parameters provide a way to configure settings related to the file format. They are configured at component level and allow you to customize how file parsing and serialization are handled.

List of file format parameters

Parameter name

File formats

Label

Help text

flatxml_key_name

  • flatxml

Nombre de la clave FlatXML

flatxml_root_name

  • flatxml

Nombre de FlatXML raíz

flatxml_value_name

  • flatxml

Nombre del valor FlatXML

json_indent

  • json

  • json-nested

  • webextension

  • i18next

  • i18nextv4

  • arb

  • go-i18n-json

  • go-i18n-json-v2

  • formatjs

  • gotext

Sangría JSON

json_indent_style

  • json

  • json-nested

  • webextension

  • i18next

  • i18nextv4

  • arb

  • go-i18n-json

  • go-i18n-json-v2

  • formatjs

  • gotext

Estilo de sangría de JSON

Elecciones disponibles:

spaces

Espacios

tabs

Tabuladores

json_sort_keys

  • json

  • json-nested

  • webextension

  • i18next

  • i18nextv4

  • arb

  • go-i18n-json

  • go-i18n-json-v2

  • formatjs

  • gotext

Ordenar claves de JSON

json_use_compact_separators

  • json

  • json-nested

  • webextension

  • i18next

  • i18nextv4

  • arb

  • go-i18n-json

  • go-i18n-json-v2

  • formatjs

  • gotext

Evitar espacios tras separadores

po_fuzzy_matching

  • po

Usar coincidencia aproximada

po_keep_previous

  • po

Conservar los msgid anteriores de las cadenas traducidas

po_line_wrap

  • po

  • po-mono

Ajuste de renglones largos

By default, gettext wraps lines at 77 characters and at newlines. With the --no-wrap parameter, wrapping is only done at newlines.

Elecciones disponibles:

77

Ajustar renglones a los 77 caracteres y en saltos (valor predet. xgettext)

65535

Only wrap lines at newlines (like xgettext --no-wrap)

-1

No ajustar renglones

po_no_location

  • po

No incluya información de lugar en el archivo

xml_closing_tags

  • ts

  • plainxliff

  • xliff

  • poxliff

  • resx

  • aresource

  • moko-resource

  • cmp-resource

  • tbx

Incluir etiqueta de cierre para etiquetas XML vacías

yaml_indent

  • yaml

  • ruby-yaml

Sangría YAML

yaml_line_break

  • yaml

  • ruby-yaml

Saltos de renglón

Elecciones disponibles:

dos

DOS (\r\n)

unix

UNIX (\n)

mac

MAC (\r)

yaml_line_wrap

  • yaml

  • ruby-yaml

Ajuste de renglones largos

Elecciones disponibles:

80

Ajustar renglones a 80 caracteres

100

Ajustar renglones a 100 caracteres

120

Ajustar renglones a 120 caracteres

180

Ajustar renglones a 180 caracteres

65535

No ajustar renglones