[GH-ISSUE #776] [META] Automatic regeneration / propagation when adding new locale #301

New issue

Open

opened 2026-02-28 00:01:11 +03:00 by kerem · 1 comment

kerem commented

2026-02-28 00:01:11 +03:00

Owner

Originally created by @tobozo on GitHub (Apr 3, 2018).
Original GitHub issue: https://github.com/SpacehuhnTech/esp8266_deauther/issues/776

While it's nice to have the translations added to the source folder, it does not add it to the compiled web interface, some manual operations are still required.

Several solutions should be available whenever a language is added or when an existing language is updated:

ability to add a language file from the deauther by uploading from the WebUI (no reflashing required)
automatic generation/re-generation + commit of the .gz files (+ideally autocommit)
automatic regeneration + commit of the language.h file (master language only)

Originally created by @tobozo on GitHub (Apr 3, 2018). Original GitHub issue: https://github.com/SpacehuhnTech/esp8266_deauther/issues/776 While it's nice to have the translations added to the source folder, it does not add it to the compiled web interface, some manual operations are still required. Several solutions should be available whenever a language is added or when an existing language is updated: - ability to add a language file from the deauther by uploading from the WebUI (no reflashing required) - automatic generation/re-generation + commit of the .gz files (+ideally autocommit) - automatic regeneration + commit of the language.h file (master language only)

kerem added the

development

translation

labels

2026-02-28 00:01:11 +03:00

kerem commented

2026-02-28 00:01:12 +03:00

Author

Owner

@tobozo commented on GitHub (Apr 9, 2018):

esp8266_deauther travis example

Any change on the repo triggers:

language file re-generation
binary compilation for 8 different hardware configs
upload of the compiled binaries on the release page

Work in progress:

dynamic CHANGELOG.md with commit list from the latest release to HEAD
multiline body on the release page (ideally the content of the changelog.md)
patching the webUI routes when a new language is added (currently only supports updating the existing)

Security:

In order to push the binaries onto a tagged release page, the Travis script requires a github token generated by repository owner (it won't work with only collaborator perms).
While the token isn't visible by anyone, the .travis.yml is still editable by collaborators as it's part of the repo.

Problem: anyone with permissions to modify the .travis.yml script can potentially add a command to use the token for any allowed github operation (e.g. poisoning the repo), while being identified as the repository owner.

Compromise:

Use Travis without github token and don't upload anything

or ...

Upload the compiled binaries somewhere else (another repo, some gh_pages, a website, etc)

or ...

Use a private installation of travis where the .travis.yml is not part of the repo

@tobozo commented on GitHub (Apr 9, 2018): esp8266_deauther [travis example](https://travis-ci.org/tobozo/esp8266_deauther) Any change on the repo triggers: ---------------------------------- - language file re-generation - binary compilation for 8 different hardware configs - upload of the compiled binaries on the [release page](https://github.com/tobozo/esp8266_deauther/releases/tag/v2.1.4) Work in progress: ------------------ - dynamic CHANGELOG.md with commit list from the latest release to HEAD - multiline body on the release page (ideally the content of the changelog.md) - patching the webUI routes when a new language is added (currently only supports updating the existing) Security: --------- In order to push the binaries onto a tagged release page, the Travis script requires a github token generated by repository owner (it won't work with only collaborator perms). While the token isn't visible by anyone, the .travis.yml is still editable by collaborators as it's part of the repo. **Problem:** anyone with permissions to modify the .travis.yml script can potentially add a command to use the token for any allowed github operation (e.g. poisoning the repo), while being identified as the repository owner. Compromise: -------------- - Use Travis without github token and don't upload anything or ... - Upload the compiled binaries somewhere else (another repo, some gh_pages, a website, etc) or ... - Use a private installation of travis where the .travis.yml is not part of the repo