Ticket #576 (closed enhancement: fixed)

Opened 3 years ago

Last modified 2 years ago

Add new widget attribute i18n= that does absolutely nothing, but also is not dismissed as Unknown GUI Attribute

Reported by: ChrisOelmueller Owned by: FIFE
Priority: low Milestone: 0.3.4
Component: engine/extensions/pychan Version: trunk
Severity: trivial Keywords:
Cc: Blocked By:
Blocking: Time planned:
Time remaining: Time spent:


With UH as use case, we extract all strings from our xml files so that we can throw them into gettext. Because some of those strings are ambiguous and hard to translate if they lack context, we added an attribute i18n="" that gets extracted as well and added as comment. Looks like this: <Label name="neutral_label" text="neutral" i18n="Diplomacy state of player" />

When we display that widget though, pychan tells us how bad we've been and throws the following:

  File "/home/eoc/UH/fife/trunk/engine/python/fife/extensions/pychan/__init__.py", line 351, in startElement
  File "/home/eoc/UH/fife/trunk/engine/python/fife/extensions/pychan/__init__.py", line 362, in _createInstance
  File "/home/eoc/UH/fife/trunk/engine/python/fife/extensions/pychan/__init__.py", line 344, in _setAttr
    raise GuiXMLError("Unknown GUI Attribute '%s' on '%s'" % (name,repr(obj)))
fife.extensions.pychan.exceptions.GuiXMLError: Unknown GUI Attribute 'i18n' on '<Label(name='__unnamed__') at 9448fcc>'

We'd thus like an attribute that is kindly ignored by pychan for the purpose of providing i18n context to translators. Choose whatever name you think fits, stuff is not urgent (right now we simply generate the .pot files in a different branch than master) but would certainly be useful to not only UH.

Using helptext= is no option by the way as that's help for players ingame (e.g. displayed per tooltip) and really does not match the same helpfulness criteria as i18n= content.

Change History

comment:1 Changed 2 years ago by prock

(In [3785]) * Fixed a small bug with basicapplication. It was grabbing a reference to the gui manager incorrectly.

  • All widgets now use named parameters exclusively. No more kwargs is being used. This prevents clients from passing arguments to the constructor that are unsupported (they are no longer silently ignored). This is still a work in progress. I have some cleanup to do around hexpand and vexpand and some other default argument values.
  • Added a "comment" attribute to all widgets. This was requested by UH. TODO add the comment attribute to all constructors. This has yet to be tested. refs #576

comment:2 Changed 2 years ago by prock

  • Status changed from new to closed
  • Resolution set to fixed

(In [3786]) This should conclude my work on tickets and . All widgets should now take all configurable properties in their constructor. All clients should used named parameters when passing in values to the constructor.

I have added a "comment" attribute to all widgets. This should allow clients to easily store a bit of extra information about a widget for their own use.

I also changed Slider and PercentageBar? to conform to the pychan standard. To get and set values to them you can use their "value" property. I had to change some code in the PychanDemo? so chances are if you are using these widgets you'll need to do the same.

Fixed the editor and all demo's to work with these changes. Hopefully I got everything.

Some notes to clients: This commit MAY change some functionality of pychan depending on how you are using it. Any parameters passed to the constructors will override any attributes set in the style even if you specify a style in the constructor. Keep this in mind! Other than that it should be exactly the same. closes #576

Note: See TracTickets for help on using tickets.