ldm 3.4.9-1

The password change speaks German again on a German client.

Its strings went through gettext() from the start and still came out English: when the Kerberos code moved into src/ldmkrb5.c in 3.4.8-1, that file was never added to po/POTFILES.in. xgettext never saw it, so no catalogue could hold what it says — and the greeter around it was German, asking for a "New password" beside Benutzername and Passwort.

The half that is easy to miss: msgmerge had already matched some of those strings to unrelated older entries and marked them fuzzy, and gettext refuses a fuzzy translation. They were English too, while looking translated in the file. One of them would have been worse than English if it had ever been shown:

"The new password does not meet the rules of this domain." → "Diesen Benutzer gibt es in der Domäne nicht."

Sixty-one messages now, none fuzzy, none open, checked against the compiled catalogue rather than the source: the prompts, the line saying the password must be changed before signing in, the mismatch notice, every reason a change can fail, and the message for an authentication server that cannot be reached. Three older strings that had never been translated came along — the reboot notice from I01-nbd-checkupdate, the question about a session elsewhere, and S15-userLoginCheck's refusal.

What deliberately stays in the domain's own language is the controller's wording when it refuses a password. "Password too short, password must be at least 7 characters long" is its sentence about its own rule, and passing it through unchanged is the whole point of showing it.

For any of this to be seen, the environment has to be German: LANG="de_DE.UTF-8" in lts.conf, and the locale has to be in the image (ltsp-build-client --locale de_DE.UTF-8,...). Where it is not, everything stays English without an error, and ldm says so in its log: locale "de_DE.UTF-8" is not generated in this image; staying in "C" and showing English.