Comment 11 for bug 541990

> >- How does the frontend behave if the backend crashes? (Throwing DBusExceptions is a common phenomenon with dbus service backed programs, and hard to get right)

> Yes, the front-end currently throws DBusExceptions. What should it do instead?

I guess it should handle them gracefully, like restarting the backend or crashing the UI as well, since otherwise the user will be left with a nonfunctioning UI. With such a lot of code changes, some exceptions will be inevitable, I figure.

> String removals

No-brainer, those are ok.

> New:

> * Non-package items to remove: {others}.
> - Helps to know what the other stuff being removed is.

OK.

> * Processing {0}
> - New progress bar text.

OK.

> * Landmark package {0.package} is missing
> * Landmark package {0.package} is not downloadable
> * Duplicate cruft with different cleanup: {0.cruft_name}
> * No such cruft: {0.cruft_name}
> - Error messages that actually shouldn't be translated!

Right, are they marked as such? Does the user actually see them? User-visible text should not use geek terminology like "landmark" (what is that even, in a packaging context?) or "cruft".

> Modified:

CLI help is fine (although it should boil down to a few removed and added strings if you use optparse properly).

Can we please avoid the other string changes? Each of these breaks all the translations which have been done by now. These might be moved to lucid+1?