Finish application internationalization

[javiereguiluz]

Right now the application defines just four translations keys. See:
https://github.com/symfony/symfony-demo/blob/master/app/Resources/translations/messages.en.xliff

We did this to have just a simple example of how to translate application interfaces using Symfony. I propose the following:

• Extract all the strings from the public interface and add them to the messages.en.xliff file
• Move all the backend related strings to the admin.en.xliff file to show an example of using translation catalogues
• Once these tasks are finished, ask the community to contribute translations.

What do you think?

[weaverryan]

I think it's a good idea - because this can serve as a good example of how to use translation keys. My only hesitation is with the admin catalogue. Won't this create some duplication (e.g. translating Save in both files)? What is the real use case for multiple catalogs? Is it only so that 3rd-party items don't run over your translations? Or is there a good use-case inside your app?

[stof]

In my own project, I keep most of my translations in the messages catalogue to keep things simple (using the dot convention to organize my keys, which allows me to benefit from the nested syntax in YAML files). My use case for a separate catalogue are emails: I have a separate catalogue with translation keys related to the content of emails sent by my app.

Regarding the split of admin messages to a separate catalogue, I guess it depends how many translations keys are actually shared between the frontend and the backend. If it is only about the Save action for forms and a few other generic actions, it may be fine to duplicate them in both catalogues, or to load them from the messages catalogue even on the backend.

[dosten]

I want to work on this, but i have a question, how we have to handle translations with HTML? Example:

<p>
    <a class="btn btn-success" href="{{ path('security_login_form') }}">
        <i class="fa fa-sign-in"></i> Sign in
    </a>
    to publish a comment.
</p>

[javiereguiluz]

@dosten great! Thanks for working on this.

When there is a little amount of HTML markup (e.g. <strong>sign in</strong>) it's usually OK to consider it part of the translated string (although strictly speaking it's not recommended). But in this case, I think there is too much HTML and we should split this content into two strings: sign in and to publish a comment.

[xelaris]

I propose to use the extension .xlf instead of .xliff, for the reason described in symfony/symfony-docs#5190.

[javiereguiluz]

@xelaris I agree with you because the given reasons are convincing to me. Thanks!

[JulienItard]

Hi,

i think we should translate Assert error message using validators.en.xlf and maybe with yml to show another way.

[JulienItard]

Any comment about my last message ?

[javiereguiluz]

@JulienItard you mean translating the contents both with XLF and YAML formats? I'm OK with that, but reminding the user that XLF is the officially recommended format. Besides, do you know what would happen in the application if we provide the exact same translations using two different fromats?

[JulienItard]

@javiereguiluz i mean use xlf format with basic translation file like message.en.xlf and yml file for doctrine translation with validator.en.yml in order to show a different way ans more complexe translation

[xelaris]

I think only the XLIFF format should be shown, as the demo app should show best practices only. Mixing two formats in a real application would be bad practice IMO.

[stof]

@javiereguiluz we should probably finish the discussion in symfony/symfony-docs#5026 first