friendly recovery does not use and has probably never used provided translations

It should work when you set your locale to pl_PL.utf8 but not pl.utf8.

How are users supposed to know that? Or is the "friendly" recovery a misnomer? Do you truly believe that setting this bug as invalid is the correct course of action?

I set it invalid in Ubuntu Translations because it's not the problem with it. But I kept the status "new" for "friendly-recovery (Ubuntu)", the problem should be there, we need someone to look into the package and figure out the hint.

Tomasz: Aron marked the bug task in the 'ubuntu-translations' project as invalid, but left the 'friendly-recovery' bug task open to keep track of it, so it's not that he was marking the bug as invalid.

Aron: I'd prefer to have the 'ubuntu-translations' bug task as New. It is a bug affecting Ubuntu translations, and we use the project to be able to have an overview of translation-related bugs and to be able to subscribe to bugmail for those type of bugs:

  https://launchpad.net/ubuntu-translations/+subscribe

Therefore, I'm setting it as New in ubuntu-translations again

After a quick look, this seems to be related to the fact that these translations are shipped in language packs (in /usr/share/locale-langpack), whereas the code refers to the non-language-pack location (/usr/share/locale) when loading translations.

Added a branch with a proposed fix

I found several problems:
- one of the scripts was not localized at all
- some were missing from POTFILES.in
- the l10n.sh script did not know which language to use, as the environment is not set in recovery mode. (code stolen from bug #528908 :))
- It seems that it is not bothered by the localedir not being /usr/share/locale-langpack

Seems that my branch was merged in:
http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/lucid/friendly-recovery/lucid/revision/13
It was also released in version 0.2.10.