> This does make me think of the interesting prospect of an internationalised > string literal, though (e.g., _"This an il8n string"). I'm not sure it would > be enough of a win over the status quo though, I don't think so either. i18n doesn't require its specific string notation (in addition, dropping "_()" may make it harder to interface with standard gettext tools). On the hand, international support in Python apps will benefit from: - seamless unicode support: how about making the default Python charset utf-8 instead of ascii ? right now, someone (say an American or English) who does not design his app with non-ascii characters in mind may have a surprise when users enter those characters in customizable fields: for example, debug print statements which end up crashing the app with an UnicodeException on the user's machine, without even a way to diagnose this when the app is a GUI app and stdout is not shown ;)) - simple formatting syntax (the current "%" operator is quite fine in that regard) As for seamless unicode support, there are also problems sometimes with filenames and filepaths: see e.g. https://sourceforge.net/tracker/?func=detail&aid=1283895&group_id=5470&atid=105470 Regards Antoine.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4