Hi,
I'm in the process of reviewing and testing the work you did this
week. Since there is still no new tag in the Git repository, and no
mention of a particular commit we should look at, I'm testing the
current state of the Git repo (commit 8c6f2609c).
Let me start with reiterating some stuff I've already mentioned over
private email a few days ago, without effect yet:
lintian overrides: I still think you should merge my lintian branch
and revert the broken half-merge that was done, as well as the dirty
workaround you put in when you saw the half-merge was breaking stuff.
Translation: please remove the attempt at a French translation; it'll
be easy to find someone to do a proper translation once strings have
settled. Having wrong translations prevent the .po file from showing
up as needing work.
Let me now comment on your progress report. I'm grouping related
things together, so the lines you wrote are reordered bellow.
> ## Current progress:
> - populate language list using list of available locales in
> /usr/share/i18n/SUPPORTED - DONE.
> - Language list should contain language's own name (e. g. 'Русский'
> for Russian') instead of current 2-letter code - DONE.
> - use existing code/UI from d-i/anaconda/ubuntu installer/ for
> language chooser if possible - partially done (PyICU utilized).
Great to see the language list is now dynamically built.
However, the sorting is wrong since some languages have their name
capitalized, while others haven't. This is very disturbing, and it
took me some time understanding why the language I was looking for was
not in the list. This kind of issues is the reason why I've repeatedly
suggested to base your work on existing code that does the right
thing, instead of spending time reinventing that wheel and doing it
wrong at the end of the day.
Also, the UI has a note that reads "the selection cannot be changed
once you press the button"; while this seems to be technically correct
(according to the debug log, selecting a language for the second time
triggers actions relative to the first chosen language), it's very
confusing UI-wise to read this, while being able to choose a language
once again, despite what the message says. If tails-greeter does not
support choosing the language a second time (which I suggested
initially to ease your task), great, but the UI must reflect it.
> - supply parameter as 'en' (or smth else suitable for locale generation -
> investigate) to locale-gen - DONE.
Great.
It would be great if the interface between this script and
tails-greeter was documented on the wiki:
https://tails.boum.org/todo/TailsGreeter/#index4h2
> - translate language widget too (move lang choice handler from
> button_clicked to list_choice)
I see you've done it since you sent your report, but I could not see
it working. Maybe the .pot/.po files must be updated to check it's
actually working? How do I update the .pot/.po files if I don't want
to wait for you to do it everytime?
> - Move locale-gen interaction to greeter from widget - DONE.
Great.
> - cleanup commented\old\dead code - DONE.
Great (well, you did it the week before actually, but why not).
[... snipped postponed items ...]
> ## Problems:
> - Some of the 'native' language names are not displayed correctly
> due to missing characters in the fonts (standard unicode squares
> shown instead). It's unclear how to filter them out because there
> are no actual errors shown in python.
Please don't spend any more time looking for a way to filter these
languages out. Preventing anyone from using Tails in Chinese would be
no way to fix the actual problem, but rather a way to hide it under
the carpet.
Anyway, installing the ttf-unifont package fixes this issue for me.
The glyphs are not that nice, but at least they are readable and
usable I believe. You probably should add this package as a dependency
of tails-greeter (debian/control).
> - The language list is fairly long: maybe some of the exotic
> languages could be filtered or black-listed before list
> population?
The list of languages spoken by human being is fairly long indeed, he
he. If the list appears too long, maybe the widget (that only uses a
small fraction of the available screen estate) is suboptimal.
I'd be sad removing languages from the list just to make it appear
shorter, and I'd rather not have to decide what language is "exotic"
and what other is not.
I suggest you let the current list alone and start a dedicated
discussion thread about this on tails-dev, providing a summary of all
information and numbers that are relevant to the discussion, since I
don't feel like deciding alone on this matter.
If we really end up support less languages, we need to list the ones
we want to support, instead of the ones we don't want to. E.g. we
could use the list of iceweasel l10n packs in Debian (apt-cache search
'iceweasel-l10n-*' | wc -l => 79 results).
> - It's yet unclear how to pass information to the session initiated
> by gdm: especially how to set env. variable and apply language &
> layout settings - probably there are some dbus hooks available.
I'm sure it can be cleared by looking at the gdm-simple-greeter code.
> - xklavier and ICU seems like the right way to work with language
> and layout data but there is no obvious way to reuse code from
> installers (anaconda, d-i) directly.
On this topic, the main resource I suggested was gdm-simple-greeter.
Even if you don't reuse code, these existing pieces of software will
at least show you how this issue is generally dealt with, i.e. what
users may expect (principle of least surprise).
> ## Near-future plans:
> - Make widget for layout choice and populate it with data obtained
> via xklavier.
> - Create version suitable for .iso build and test.
> - Next week plans.
> ## Additional notes:
> - Part of the code has been merged back to gdm-community-greeter
> project via special branch.
Where can it be seen? I was not able to see this in the g-c-g code on
Launchpad.
> - The general 'id' for the locale looks like ru_RU (language-country
> code) - see man localedef'. What's the acceptable id for layout is
> still unclear.
Do you mean "the xklavier API is unclear" or "I have not looked at the
xklavier API yet"? I'm not sure such an id exists at all.
Now come a few other comments.
Pressing the Enter key in the password prompt does not move forward.
It should.
Naming widgets "combobox1" makes it a pain to maintain the code later
on. Please name widgets in a more explicit way.
See you tomorrow on IRC, cheers,
--
intrigeri <intrigeri@???>
| GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
| OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc
| The impossible just takes a bit longer.
