WARNING: You are browsing the documentation for Symfony 2.5 which is not maintained anymore. Consider upgrading your projects to Symfony 4.3.

Internationalization

2.5 version

Maintained

3.4 4.2 4.3 current 4.4 master

Unmaintained

2.3 2.6 2.7 2.8 3.0 3.1 3.2 3.3 4.0 4.1

Internationalization¶

Internationalization and localization adapt the applications and their contents to the specific region or language of the users. In Symfony this is an opt-in feature that needs to be enabled before using it. To do this, uncomment the following translator configuration option and set your application locale:

# app/config/config.yml
framework:
    # ...
    translator: { fallback: "%locale%" }

# app/config/parameters.yml
parameters:
    # ...
    locale:     en

Translation Source File Format¶

The Symfony Translation component supports lots of different translation formats: PHP, Qt, .po, .mo, JSON, CSV, INI, etc.

Best Practice

Use the XLIFF format for your translation files.

Of all the available translation formats, only XLIFF and gettext have broad support in the tools used by professional translators. And since it's based on XML, you can validate XLIFF file contents as you write them.

Symfony 2.6 added support for notes inside XLIFF files, making them more user-friendly for translators. At the end, good translations are all about context, and these XLIFF notes allow you to define that context.

Tip

The Apache-licensed JMSTranslationBundle offers you a web interface for viewing and editing these translation files. It also has advanced extractors that can read your project and automatically update the XLIFF files.

Translation Source File Location¶

Best Practice

Store the translation files in the app/Resources/translations/ directory.

Traditionally, Symfony developers have created these files in the Resources/translations/ directory of each bundle.

But since the app/Resources/ directory is considered the global location for the application's resources, storing translations in app/Resources/translations/ centralizes them and gives them priority over any other translation file. This lets you override translations defined in third-party bundles.

Translation Keys¶

Best Practice

Always use keys for translations instead of content strings.

Using keys simplifies the management of the translation files because you can change the original contents without having to update all of the translation files.

Keys should always describe their purpose and not their location. For example, if a form has a field with the label "Username", then a nice key would be label.username, not edit_form.label.username.

Example Translation File¶

Applying all the previous best practices, the sample translation file for English in the application would be:

<!-- app/Resources/translations/messages.en.xliff -->
<?xml version="1.0"?>
<xliff version="1.2" xmlns="urn:oasis:names:tc:xliff:document:1.2">
    <file source-language="en" target-language="en" datatype="plaintext" original="file.ext">
        <body>
            <trans-unit id="1">
                <source>title.post_list</source>
                <target>Post List</target>
            </trans-unit>
        </body>
    </file>
</xliff>

This work, including the code samples, is licensed under a Creative Commons BY-SA 3.0 license.