Merge lp://qastaging/~mterry/snapcraft/gettext into lp://qastaging/~snappy-dev/snapcraft/abandoned-go-trunk
| Status: | Merged |
|---|---|
| Approved by: | Michael Terry |
| Approved revision: | 7 |
| Merged at revision: | 5 |
| Proposed branch: | lp://qastaging/~mterry/snapcraft/gettext |
| Merge into: | lp://qastaging/~snappy-dev/snapcraft/abandoned-go-trunk |
| Diff against target: |
371 lines (+229/-6) 14 files modified
cmd/snapcraft/cmd_scratch.go (+6/-2) cmd/snapcraft/cmd_scratch_info.go (+6/-3) cmd/snapcraft/main.go (+7/-0) config/yaml.go (+3/-1) dependencies.tsv (+2/-0) gen-coverage.sh (+2/-0) helpers/dirs.go (+46/-0) helpers/dirs_test.go (+50/-0) make-snap (+27/-0) package.yaml (+7/-0) po/en_US.po (+16/-0) po/snapcraft.pot (+34/-0) run-checks (+7/-0) update-pot (+16/-0) |
| To merge this branch: | bzr merge lp://qastaging/~mterry/snapcraft/gettext |
| Related bugs: |
| Reviewer | Review Type | Date Requested | Status |
|---|---|---|---|
| Michael Vogt (community) | Approve | ||
|
Review via email:
|
|||
Commit message
Add gettext support to snapcraft.
This wasn't an urgent change at all. But I was curious what a gettext-enabled Go project might look like (as Go's build system doesn't seem to cater to data files). Since snapcraft only has a little bit of code and few messages, it was an easy task to tackle.
I chose the "github.
https:/
- I added a helpers/dirs.go file to locate our data files at run time (supporting both a snapified mode and a deb mode).
- I added a script to update the pot file and a check in run-checks that makes sure if you change any strings, you know you need to update the pot file.
- I added a dummy package.yaml and a simple make-snap script to make an example snap (I wanted to see what it would look like to distribute the .mo files, plus it's good to be able to make a snap for testing purposes)
- I added a dummy en_US.po null translation just as an example (so I could see *something* installed in the locales folder). We can drop it later when we have real translations.
I don't think we should enable translations in LP yet, since all our strings are provisional. But I just wanted to lay the groundwork.
I tested this locally (locale changing in a snappy system doesn't work?) with a fake translation and it seemed to work.
Description of the change
Add gettext support to snapcraft.
This wasn't an urgent change at all. But I was curious what a gettext-enabled Go project might look like (as Go's build system doesn't seem to cater to data files). Since snapcraft only has a little bit of code and few messages, it was an easy task to tackle.
I chose the "github.
https:/
- I added a helpers/dirs.go file to locate our data files at run time (supporting both a snapified mode and a deb mode).
- I added a script to update the pot file and a check in run-checks that makes sure if you change any strings, you know you need to update the pot file.
- I added a dummy package.yaml and a simple make-snap script to make an example snap (I wanted to see what it would look like to distribute the .mo files, plus it's good to be able to make a snap for testing purposes)
- I added a dummy en_US.po null translation just as an example (so I could see *something* installed in the locales folder). We can drop it later when we have real translations.
I don't think we should enable translations in LP yet, since all our strings are provisional. But I just wanted to lay the groundwork.
I tested this locally (locale changing in a snappy system doesn't work?) with a fake translation and it seemed to work.
| Michael Terry (mterry) wrote | # |
Hey Michael! This is really great stuff. I used it as the blueprint for snappy and created a lp:~mvo/snappy/snappy-gettext branch. I put some inline comments (mostly because I just write down there whats in my mind) but none of those is important, this is cool stuff and can be merged as it is.