Opened 9 years ago

Closed 7 months ago

#14612 closed defect (outdated)

new wxCmdLineEntryDesc breaks i18n

Reported by: keinstein Owned by:
Priority: normal Milestone:
Component: base Version: 2.9.4
Keywords: closed-due-to-info-needed Cc:
Blocked By: Blocking:
Patch: no

Description

Hi,

changing the description field of wxCmdEntryDesc leads to a strange design:

  • it prevents internationalization macros from working as N_() and _() are translating character strings to (const) wxChar *.
  • it complicates the build process as the defaults for xgettext do not work anymor
  • it does not simlify the string handling as wxGetTranslation is called anyway.
  • it moves control of input character translation from the C++ compiler to wxWidgets in contrast to all other string constants. This can confuse developers in case of problems.

Change History (6)

comment:1 Changed 9 years ago by vadz

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

I don't understand all your points (e.g. what do you mean about xgettext defaults?) but FWIW I do agree that the situation with this struct is not ideal. Unfortunately there is just not much we can do about it. I recommend using AddXXX() functions instead of table-based initialization.

As for i18n, you just need to use wxTRANSLATE() or gettext_noop(), and I don't see any real problem with that.

comment:2 follow-up: Changed 9 years ago by keinstein

Autoconf/Automake based projects call xgettext with --keyword=_ and --keyword=N_ by default. Everything else needs tweeking the build system. It's certainly not hard, but forces the developer to rediscover knowledge that he safely forgot. And: Never touch a running system…

I was happy with my current build system. So far I could use the defaults that had been introduced at some time using gettextize.

Now you force me to revise my build system to support a structure that
a) is inconsistent with the rest of the design of the library
b) pretents to be low level, but triggers hidden character set conversions.
c) is a singularity with respect to i18n

Btw. wxTRANSLATE and gettext_noop is nothing that I want to see in a static initialization. They are both too long.

Using AddXXX directly is indeed probably the best solution. Though using tables looks more effective, WX uses these functions internally anyway…

comment:3 in reply to: ↑ 2 Changed 9 years ago by vadz

Replying to keinstein:

Autoconf/Automake based projects call xgettext with --keyword=_ and --keyword=N_ by default.

It also recognizes gettext_noop() by default which can be used here.

Now you force me to revise my build system to support a structure that
a) is inconsistent with the rest of the design of the library
b) pretents to be low level, but triggers hidden character set conversions.
c) is a singularity with respect to i18n

Sorry, I don't understand (b), I don't think we pretend anything at all nor do we trigger any conversions. The original strings should be in ASCII anyhow. (c) does have some merit but, again, I don't see what to do about it.

Btw. wxTRANSLATE and gettext_noop is nothing that I want to see in a static initialization. They are both too long.

So what do you use for the strings that should be extracted by xgettext but not translated immediately in the rest of your code?

comment:4 Changed 9 years ago by keinstein

  • Resolution wontfix deleted
  • Status changed from closed to reopened

I'm reopening for one word: ASCII: its ASCII and not ISCII. ASCII has never been a good choice for a character set see http://en.wikipedia.org/wiki/ASCII and it is sufficient only for very few languages of the world. I know only three languages that are ASCII compatible: Latin (spoken in an area of 0.4 square kilometers), swiss German and English. Many languages use the slots of this encoding only for punctuation if they use them at all. Though I think that English is not a bad choice for internationalized software, it is definitively for non-internationalized software.

By the way you are wrong regarding charcater set conversion: wxCmdLineParser::SetDesc calls wxGetTranslation(const wxString&, const wxString&). As wxString is a string of wxChars (which are usually unicode compitible) that forces a character set conversion as long as wxWidgets is unicode compatible (regardless whether it internally uses UTF-8 or UCS-2 or UCS-4). Especially UTF-8 needs a conversion as any useful ISO-8859-x character sequence contains invalid characters in UTF-8.

If you are not convinced: On MAC OS X without further arguments setup.h defines WX_USE_UNICODE to 1 at least in current trunk.

comment:5 Changed 9 years ago by vadz

  • Status changed from reopened to infoneeded_new

Yes, without i18n it's impossible to use non-ASCII characters in this struct. What can I say? Use i18n or use AddXXX(). Is this such a big problem in practice?

We can consider reverting this change and use const wxChar* for these fields. But it would be awkward to have exactly one place of wxWidgets where you'd have to use wxT(). I'd really like to avoid it.

Notice that using wxChar instead of char wouldn't change anything with your other grievances, e.g. you'd still need to use gettext_noop() and not _(), you'd still possibly have a conversion from wchar_t to UTF-8 in some builds.

Again, I'd really love you to present a clear case for changing this because I'm quite lost: you open a bug for "i18n breakage" but then, without clearly explaining how exactly is i18n broken, it turns out that things are actually broken when i18n is not used at all. I'm confused and would prefer to not change anything at this stage without a much better understanding of both the problems with the current code in practice and potential gains.

comment:6 Changed 7 months ago by vadz

  • Keywords closed-due-to-info-needed added
  • Resolution set to outdated
  • Status changed from infoneeded_new to closed

This ticket has been closed because no information needed for resolving it was provided.

If the ticket is still valid, please reopen it and please try to answer the remaining questions if possible.

Thanks in advance!

Note: See TracTickets for help on using tickets.