PWorker(threading.Thread) from luci/lib/ricci_helpers represents
a partly separated environment from its per-request thread.
One of the side-effects is that "translator" is not present
natively as in case of the framework-managed threads.

As a consequence, a request towards ricci handled by PWorker
can, if any error/exception occur, can be silently dropped.
The symptoms are:
- unexpected behavior: looks like the action has never been initiated
  by the user
- messages like these in /var/log/luci/luci.log:

16:15:45,344 ERROR [luci.lib.ricci_helpers]
  No object (name: translator) has been registered for this thread
16:15:45,350 ERROR [luci.lib.ricci_helpers]
  Error retrieving batch number from rhel63-64kvm-1:
  No object (name: translator) has been registered for this thread

This is due to such circumstances that fulfillment of request towards
ricci (done via PWorker/private threading) will fail and the message
to be presented to the user is arranged as lazily translated string.
Apparently, this works well outside private threading (so the user
is informed correctly about the problem), but fails in private
threading environment lacking the explicitly set translator.


Based on brief investigation, there are two options to solve this:
a/ make lazily translated strings as standard strings
   - easy, but non-systemic solution
b/ try to register translator object in the private threading
   environment
   - seems like a right way to solve it
   - see [1] for further hints


Tested reproducer:

1. cluster added into luci
2. within luci, select specific cluster, then fence devices tab
3. add any fence device, using non-ascii for, e.g., name

Expected behavior in this case is that the user is visually
informed in the spirit of "this went wrong".  Currently, nothing
happens from user's standpoint, previous page is just refreshed.


[1] http://comments.gmane.org/gmane.comp.web.turbogears/46896