After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 99005 - UTF-8 trouble
UTF-8 trouble
Status: VERIFIED FIXED
Product: intltool
Classification: Deprecated
Component: general
unspecified
Other All
: High normal
: ---
Assigned To: intltool maintainers
intltool maintainers
: 117958 (view as bug list)
Depends on: 119613
Blocks: 85718 101420 115441 119008
 
 
Reported: 2002-11-19 15:21 UTC by Morten Welinder
Modified: 2009-08-15 18:40 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
aforementionted patch that includes Carlos' patch (12.57 KB, patch)
2003-07-20 08:06 UTC, Abel Cheung
none Details | Review

Description Morten Welinder 2002-11-19 15:21:24 UTC
Gnumeric has started including UTF-8 strings in the source using C-level
escapes.  (See bug 85718.)

This causes xgettext to complain.

intltool needs to somehow shut up this warning.  The idea thing would be
for intltool to know that we're dealing with UTF-8 and pass some flag
(which does not yet exist, mind you) to xgettext to make it happy.

Alternatively, intltool could filter out the warning from xgettext.

To the extent that this is a xgettext problem, please pass it down the
food chain.
Comment 1 Kenneth Rohde Christiansen 2002-11-21 16:07:32 UTC
I think we should just filter it out for now. If you could send me a
small patch, that would be perfect. If not, I will look at it when I
hav e time.
Comment 2 Morten Welinder 2002-12-17 14:21:01 UTC
Filtering out is not trivial since, I imagine, that the error message
is likely to be translated.
Comment 3 Kenneth Rohde Christiansen 2003-01-05 17:12:06 UTC
Morten, do you mind filing a bug at gettext?
Comment 4 Morten Welinder 2003-01-05 18:48:42 UTC
I did a month ago, but I have heard nothing -- not a single "0" or "1"
from them.
Comment 5 Christian Rose 2003-06-04 10:04:34 UTC
This seems to have been fixed in later gettext versions:
http://lists.gnome.org/archives/gnome-i18n/2003-May/msg00139.html

Quote:
  "xgettext now supports msgid strings in other encodings than ASCII.
  xgettext has a new option --from-code that specifies the encoding
  of the source files. The resulting POT files are UTF-8 encoded."

Would this mean that intltool needs to have a dependency on newer
gettexts?

Btw, I don't see how just filtering out as mentioned in the beginning
of this report would solve the problem.
Comment 6 Morten Welinder 2003-06-23 14:47:11 UTC
Confirming that adding "--from-code=UTF-8" to the xgettext line
fixes things in gettext 1.12.1.

I suggest that intltools immediate starts using this option when
available, but without an explicit dependency yet.

Upping priority -- this has got to be a Gnome-wide problem that now
even has a solution.
Comment 7 Abel Cheung 2003-07-20 08:04:06 UTC
Carlos has a patch posted on gnome-i18n that mostly addressed this
problem, which tries to autodetect file encoding. I've enhanced a bit
so that one can manually override the choice.

To try the patch, add "[encoding:UTF-8]" as the first line in
POTFILES.in (mlview is a good choice for testing), and run patched
intltool-update with "-p" option.

changelog is not in the patch yet.
Comment 8 Abel Cheung 2003-07-20 08:06:03 UTC
Created attachment 18451 [details] [review]
aforementionted patch that includes Carlos' patch
Comment 9 Abel Cheung 2003-07-20 08:31:49 UTC
missed one point. This patch needs gettext >= 0.12.
Comment 10 Carlos Perelló Marín 2003-08-01 07:53:58 UTC
Next status pages update will have this patch applied.
Comment 11 Abel Cheung 2003-08-03 21:34:32 UTC
*** Bug 117958 has been marked as a duplicate of this bug. ***
Comment 12 Carlos Perelló Marín 2003-08-11 20:02:15 UTC
This bug is fixed with latest intltool.

Now gnumeric need intltool >= 0.27 and has a requirement.

ALL strings that should be translated, should be using UTF-8 (or ASCII)

NOTE: We are working now with SUN people to fix this issue also with
their gettext implementation. But I think that they will use GNU
xgettext because it's the easiest solution, so I'm going to close this
bug.