<davidz> mezcaler1: so udisks now allows you to clear data before formatting a disk (in various ways, write zeroes or using ATA secure erase). Bottom-line is that these operations easily take hours....
<davidz> mezcaler1: so the natural thing to do is to use http://www.freedesktop.org/wiki/Software/systemd/inhibit
<davidz> mezcaler1: however... I'm a system-level process... so the @who and @why parameters are suspect
<davidz> mezcaler1: in terms of i18n and l10n
<davidz> (geek-speak for grown ups)
<davidz> mezcaler1: so... I'd say that this API is kinda busted. I wonder how open you are to repairing it...
<davidz> mezcaler1: one way to repair it could be to impose a protocol on the strings... for example, could mandate that i18n:gettext-domain=udisks2;gettext-message=Hello%20World means: use gettext(3) from the client app with gettext-domain 'udisks2' and untranslated string "Hello World"
<davidz> mezcaler1: that's sorta how polkit does it and it can be made to work fine
<davidz> mezcaler1: notably you would be able to do this (almost) without breaking your API....
Kay also mentioned that this is a problem in multi-seat environments - for example, if you have two seats, one in en_US.UTF-8 and one in da_DK.UTF-8 and the latter is burning a CD you don't want to see a Danish message saying "Er ved at brænde en CD, vent lige et øjeblik fætter!" in the en_US session...
Just for the record, here's the udisks commit that adds support for systemd inhibitor locks
Btw, to support non-trivial and more useful inhibitor messages, the protocol should support strings like
The client will use gettext(3) to expand this to
Formatting Device $(device)
Formatterer enhed $(device) # da_DK
and then the client also replaces all instances of $(foo) with the value of variable.foo so we get
Formatting Device /dev/sda1
Formatterer enhed /dev/sda1 # da_DK
Again, this is pretty much how polkit works, see
for an example.
Hmm, so we actually do maintain a system locale these days which we pass to all system services. I'd simply assume that system services use that locale for all their messages.
This would of course mean that if the system locale is "fr_FR" and the session locale is "de_DE" and you try to reboot, then you'll see a french app blocking your reboot, but i'd claim that is OK, no?