Fallback for internationalized routes

Thomas Calvet
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

Chris Wilkinson
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

Yonel Ceruto
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

Alexis Boyer
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

Yonel Ceruto
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
Published in #Living on the edge