A while ago I set up subiquity for translations at
https://translations.launchpad.net/subiquity by uploading the pot and po
files that were current at the time and set it to export translations to
lp:~canonical-foundations/subiquity/translations-export (unfortunately,
launchpad translations only support exporting to bzr). This commit
contains the po files from that branch. The diff is noisy but I don't
think there are many actual changes (although there are a few so some
people must have found this).
I haven't publicized this or asked the ubuntu-translators team to work
on the translations because I am still uncertain about what the best way
to manage translations for subiquity is. But this still seems better
than nothing.
Getting the apt packages needs to be first, as processing probert is
more than a trivial git clone and needs some of those apt packages.
Drop probert as a requirement since it's redundant with the git
checkout.
consider the following scenario, admittedly one that is not possible
today:
* There is an "install model" that is required for server and not
desktop (let's say "mirror")
* The user initially selects a desktop install and moves through the
screens until they are asked for confirmation.
* At this point the user moves back through the screens and selects a
server variant. Now the application state of NEEDS_CONFIRMATION is
misleading; the state needs to move back to WAITING until the mirror
model is configured.
This is all probably excessively general but I feel like the core
control flow of the installer needs to be able to handle this sort of
thing...
a while ago I rewrote inject-subiquity-snap in python, generalized it
and put it at https://github.com/mwhudson/livefs-editor. TBH, it's
always been better than the shell version but now there's a reason to
switch to it: the impish live server ISO use layers, which the current
shell scripts do not support and livefs-editor now does.
The original design for timezone intentionally set the system timezone
based on geoip results, before a POST /timezone. After the feedback on
LP: #1936310 I'm having second thoughts on that and wish for GET to be
a simple informational query with no such side effects.