RFC: Backend translations

[emlove]

Description

As of yet, we haven't tackled the problem of how to manage translations that are platform specific. I started a WIP PR with one approach, but I wanted to take a moment to get some more opinions.

Right now I see two approaches, detailed above. I started briefly with approach 1, but I'm starting to suspect that 2 will be easier to maintain in the long run. I think in reality, we're never going to need the flexibility that approach 1 would give us, and we could always revisit it later if it really came down to it.

1. Serve translations from the backend

This is the approach I started with the #12453. In this world, platforms will register their strings with the frontend component, which can then serve these translations to clients via an API endpoint. We will have two projects in Lokalise, the current polymer project, and a new project for backend translations.

Pros

• Extremely flexible. The server could potentially add/remove translations at runtime, using any logic that makes sense.
• Separation of interests. The polymer project remains unaware of all our platforms. Strings specific to any one component/platform stay in the same codebase, and we don't have to coordinate PRs across multiple projects.
• Custom components are supported as well.

2. Merge platform-specific translations into the polymer project

In this approach, we would merge platform-specific translations into our current translation source, under their own component/platform namespace. We would then use the existing translation fragment logic to fetch the strings for each platform that is loaded in hass.

Pros

• Utilizes existing infrastructure. This is pretty much it, but it's a big one. All of the translation syncing, compiling, caching, and serving is already written. It isn't really desirable to duplicate this infrastructure on the backend in Python, or hack in js to reuse our gulp tasks.
• Display concerns stay in the frontend. This is really just the reverse interpretation of the second bullet point from 1, but it also isn't the worst thing to keep these translation sets out of the backend project.

Use Cases to consider

Configuration prompts:
https://github.com/home-assistant/home-assistant/blob/c7c0df53aab8e5cd22e7d5973e406e8d0a34b152/homeassistant/components/light/hue.py#L72-L84
Custom sensor states:
https://github.com/home-assistant/home-assistant/blob/c7c0df53aab8e5cd22e7d5973e406e8d0a34b152/homeassistant/components/sensor/season.py#L24-L27

[balloob]

Since they are never shown in the backend, I think it's fine to keep them as part of the frontend. Let's just make sure that they can be loaded on demand.

With config entries we're going to have a lot of strings in the backend that need to be shown in the frontend. Although for now I have them as text, I plan on replacing them with translation keys before the official release of config entries.

[balloob]

We will just need another script in the backend to upload translations to lokalise. I guess we should do that to a separate lokalise project. (but still just include the project in the frontend)

[andrey-git]

Unless I'm missing some missing something, I think (1) is much better.

First HA (backend) should be usable in non-English for users of UIs other than the official one.
Second, even for official UI it would be great if custom (backend) components were supported. If all texts come from lokalise - this is impossible.
Last, I think project separation is nice - i.e. don't mix frontend and backend where not necessary.

[emlove]

So it sounds like we're leaning towards option 1?

@andrey-git's point about custom components certainly is enough to tip the scales for me. Updated the summary to also include @balloob's point that this will be a second project in Lokalise.

[balloob]

Option 1 👍