False positive: width field

[na-Itms]

Hello, I am facing a false positive occurrence when using Dennis to check the translations of 0 A.D..

We have one place where we use the format %(name)4s to pad the result to at least 4 characters. Dennis throws a 'type missing' error when reading that.

You can reproduce it with http://trac.wildfiregames.com/browser/ps/trunk/binaries/data/mods/public/l10n/ar.public-gui-other.po

Working on: /path/to/ar.public-gui-other.po
E101: type missing: %(fps)
94:msgid "FPS: %(fps)4s"

Thanks for the work on Dennis, it's a very nice tool! 😃

[willkg]

I'll look into this today.

[willkg]

I checked. python-format (which is what I think you're using here) doesn't support padding. More formally, on this page:

https://docs.python.org/2/library/stdtypes.html#string-formatting-operations

it doesn't support 3, 4, 5 and 6.

I think when I originally implemented this, I wanted to discourage those bits in the actual translation strings since our translators would often mess it up.

Plus I wasn't sure how to handle them in the lint rules. Is it ok to change the justification when switching between LTR and RTL languages? Does that inherently change the token? Is it ok to change the precision? Etc.

Looking at your .po file, it says javascript-format in a bunch of places. Is that the predominant variable format you're using? If so, then maybe it's better to just implement javascript-format support.

[na-Itms]

Yes indeed, we use mainly javascript-format (and c-format for the very few strings that are hardcoded in the game engine, like the one in #98). Thanks for pointing out the different gettext formats, I hadn't realized that python-format was the one used by Dennis by default.

We have very few strings using formats that are not supported in Python, so I think we can get away by disabling linting on those specific strings, until Dennis has the support.

Thanks again for the answer, and looking forward to seeing more formats in Dennis. Should I rename the issue to mention javascript-format?