GNOME Bugzilla – Bug 310167
Borken handling of a translation
Last modified: 2005-08-05 21:23:25 UTC
Hi, it seems gcalctool lets translators change the string "ans" to anything they want, but also expects to find "ans" to work. The sv locale and others suffer from the problem: gcalctool is behaving weirdly and shows a reg sign when started. Setting the message "gcalctool/syntax_translation.c:40" to anything else than "ans" causes this behavior. I suppose this is because do_expression() expects to find Ans in the expression? The translations bg, ca, cy, da, de, et, lt, nl, pt_BR, sv, and possibly others are affected. This is Debian bug http://bugs.debian.org/317846. Bye,
Assigning to Sami as this is in his code.
The ans is internal symbol, which should not be visible to user. It should not be translated so it does not belong to the list of translated words. I don't have bg, ca, cy, da, de, et, lt, nl, pt_BR, sv locales in my machine, but can somebody test if removing the ans from the words struct in syntax_translation.c helps?
Hi, I removed ans from words in syntax_translation.c (I removed the line), rebuilt, cd po/ && intltool-update sv, change to root, msgfmt po/sv.po -o /usr/share/locale/sv/LC_MESSAGES/gcalctool.mo. It did *NOT* solve the problem, I have no idea why. I checked po/sv.po, the translation has been removed (is commented), I msgfmted po/sv.gmo too, and I msgunfmted /usr/share/locale/sv/LC_MESSAGES/gcalctool.mo to be sure. While we're at it, please add: CLEANFILES = libparser.a to gcalctool/Makefile.am as currently "make clean" will leave that one behind. (Oh and libparser.a has whitespaces instead of TAB in the "gcalctool_LDADD" definition.) Please let me know if I did not take the necessary steps to check what you suggested. Bye,
Can you add two printf calls to ce_parse_() (in ce_parse.c) and print parser_state.buff before and after translate_tokens() call? In this way we could see what is given to the parser.
Grmpf, I don't understand what I did yesterday, but I've rebuilt gcalctool today with yesterdays .mo still in place (ie. without the ans translation), and it was working nicely. The output when it works nicely is: parser_state.buff: Ans parser_state.buff: ans parser_state.buff: Ans parser_state.buff: ans parser_state.buff: Ans parser_state.buff: ans (Ans is prior the translate, and ans is after the translate) Then I installed po/sv.gmo into /usr/share/locale/sv/LC_MESSAGES/gcalctool.mo, the problem came back, and the output was: parser_state.buff: Ans parser_state.buff: Ans parser_state.buff: Ans parser_state.buff: Ans parser_state.buff: Ans parser_state.buff: Ans So I suppose the correct fix was pointed out yesterday, but I was doing something strange, or did not update everything. Bye,
Created attachment 50192 [details] [review] The Fix. The fix. Removes "ans" from the list of translated words.
Committed the fix to CVS HEAD.
Additional fix. Now when Ans is not processed by syntax translation, its written form must be exactly "Ans". Changed in ce_tokeniser.l: "ans" -> "Ans".