jeena/home-assistant.github.io
1
0
Fork 0
Code Issues Pull requests Projects Packages Wiki Activity Actions

Merge remote-tracking branch 'origin/current' into next

Browse source
This commit is contained in:
Paulus Schoutsen 2018-03-14 17:15:23 -07:00
commit 47e1b3c171
30 changed files with 1257 additions and 93 deletions
Download patch file Download diff file Expand all files Collapse all files

8
source/developers/architecture.markdown
View file

@ -7,7 +7,7 @@ sidebar: true
comments: false
sharing: true
footer: true
og_image: /images/architecture/ha_architecture.png
og_image: /images/architecture/ha_architecture.svg
---
Before we dive into the Home Assistant architecture, let's get a clear overview of the home automation landscape as a whole. This way, we can show how the different parts of Home Assistant fit into the picture.
@ -19,9 +19,9 @@ For more information about each part in this overview, <a href='/blog/2014/12/26
* Smart Home triggers commands based on previous behavior.
<p class='img'>
<a href='{{site_root}}/images/architecture/home_automation_landscape.png' name='landscape'>
<a href='{{site_root}}/images/architecture/home_automation_landscape.svg' name='landscape'>
<img alt='Home Automation landscape'
src='{{site_root}}/images/architecture/home_automation_landscape.png' />
src='{{site_root}}/images/architecture/home_automation_landscape.svg' />
</a>
Overview of the home automation landscape
</p>
@ -34,7 +34,7 @@ The Home Assistant core is responsible for Home Control. Home Assistant contains
* **Timer**: sends a `time_changed` event every 1 second on the event bus.
<p class='img'>
<a href='/images/architecture/ha_architecture.png' name='architecture'>
<a href='/images/architecture/ha_architecture.svg' name='architecture'>
<img src='/images/architecture/ha_architecture.svg' />
</a>
Overview of the Home Assistant core architecture

34
source/developers/internationalization/backend_localization.markdown
View file

@ -11,9 +11,41 @@ ha_release: 0.64
---
## {% linkable_title Translation Strings %}
Platform translation strings are stored as JSON in the [home-assistant](https://github.com/home-assistant/home-assistant) repository. These files must be located adjacent to the component/platform they belong to. They are named `strings.<component/platform name>.json`, unless the component being translated exists in its own directory, in which case the file is simply named `strings.json` in that directory. This file will contain the different strings that will be translatable. Currently only states are supported by the frontend.
Platform translation strings are stored as JSON in the [home-assistant](https://github.com/home-assistant/home-assistant) repository. These files must be located adjacent to the component/platform they belong to. Components must have their own directory, and the file is simply named `strings.json` in that directory. For platforms, they are named `strings.<platform name>.json` in the platform directory. This file will contain the different strings that will be translatable.
In order to test changes to translation files, the translation strings must be compiled into Home Assistant’s translation directories by running the following script:
```bash
$ script/translations_develop
```
After the pull request with the strings file is merged into the `dev` branch, the strings will be automatically uploaded to Lokalise, where contributors can submit translations. The translated strings in Lokalise will be periodically pulled in to the home-assistant repository.
## {% linkable_title States Localization %}
The first step when localizing platform states is to ensure that the states defined in the actual platform code are defined in `snake_case`. The states should not contain capital letters or spaces. Next, the strings file needs to be created. The states should exist under the `state` key, and map the backend state keys to their English translations. [The season sensor localization](https://github.com/home-assistant/home-assistant/pull/12453/commits/bb2f328ce10c3867990e34a88da64e2f8dc7a5c4) is a good example.
## {% linkable_title Configuration Flow Localization %}
The translation strings for the configuration flow handler are defined under the `config` key. An example strings file below describes the different supported keys:
```json
{
"config": {
"title": "This title is shown in the integrations list",
"step": {
"init": {
"title": "The user visible title of the `init` step.",
"description": "Markdown that is shown with the step.",
"data": {
"api_key": "The label for the `api_key` input field"
}
}
},
"error": {
"invalid_api_key": "This message will be displayed if `invalid_api_key` is returned as a flow error."
},
"abort": {
"stale_api_key": "This message will be displayed if `stale_api_key` is returned as the abort reason."
}
}
}
```