Fallback for internationalized routes¶

Contributed by
Thomas Calvet
in #27957.

In complex internationalized apps it's common to define different contents for each regional locale (e.g. en_GB for British English and en_US for American English). However, routes (or at least some of them) could be the same for all regions, so it's cumbersome to define duplicated routes:

1
2
3
4
5
6
7
8
9

use Symfony\Component\Routing\Annotation\Route;

/**
 * @Route({ "en_GB": "/about-us", "en_US": "/about-us" }, name="about")
 */
public function about()
{
    // ...
}

In Symfony 4.2 you can define internationalized routes without the region part and Symfony will match them ignoring the region part of the locale:

1
2
3
4
5
6
7

/**
 * @Route({ "en": "/about-us" }, name="about")
 */
public function about()
{
    // ...
}

In this example, both en_GB and en_US will match the en route.

ICU parent locales as fallback locales¶

Contributed by
Chris Wilkinson
in #28070.

Currently, when some content is not found for some locale (e.g. es_AR for Argentinian Spanish) Symfony uses the region-less locale (es in this case) as the fallback locale.

However, the ICU project defines "parent locales" for some languages (English, French, Spanish, Portuguese, etc.) In Symfony 4.2 we now use those parents as the first fallback locale. The previous example will now work as follows:

• Use es_AR content if it exists;
• Otherwise, fallback to the es_419 parent locale (which is the "international Spanish for Latin America and Caribbean region");
• Otherwise, fallback to es.

Identity translator as fallback¶

Contributed by
Yonel Ceruto
in #28523.

When using certain features of Symfony Forms in an application that hasn't installed the Translation component you may find errors like "The helper "translator" is not defined".

In Symfony 4.2 we've added an "identity translator" helper which acts as fallback when the Translation component is not installed. This identity translator doesn't actually translate anything and it just returns the given content.

Update XLF translations by default¶

Contributed by
Alexis Boyer
in #27935.

XLIFF is officially recommended by Symfony as the format to use for your translations. That's why in Symfony 4.2 the translation:update command has changed the default value of its output-format option from yml to xlf.

It's a minor change, but it will save you from typing --output-format=xlf when running this command.

Lint multiple XLIFF dirs or files¶

Contributed by
Yonel Ceruto
in #28522.

The lint:xliff command has also improved in Symfony 4.2 to support linting multiple directories and files at once.

Moreover, the command is now much faster to execute because the validation is done using local XSD files. This will solve the timeout problems you may have found in the past.

1
2

$ ./bin/console lint:xliff translations/messages.en.xlf translations/messages.es.xlf
$ ./bin/console lint:xliff translations/ legacy_translations/ data/translations/messages.en.xlf