Uwe Stöhr schrieb:
Yes, but in this case we need an en.po to be able to get it right when
using English menus.
So I created one as this was also suggested by Abdel. Using this fixes the bug.
thanks again for your help and regards
Uwe
Andre Poenitz schrieb:
I need "„text“" and not a plain ASCII string!
You need "„text“" in the translated string, not in the source string.
OK, I reverted my commit and updated the po files accordingly.
Typically source string and English translations are similar, if not
the same. But there
On Mon, Aug 04, 2008 at 01:28:22AM +0200, Uwe Stöhr wrote:
> So that means that one is forced to use English a design language? What
> about users that wants to write a small program only in German and want
> to fill a combobox e.g. with "grün"?
Minimum trouble would be "gruen" and provide a "Ge
Andre Poenitz schrieb:
The string in the source is basically an id in string form. There
is no conceptional difference between "„text“" and "Fo-bar-0x341e3",
except that the latter is 7-bit-clean and won't confuse translation
systems.
"Fo-bar-0x341e3" gives me "Fo-bar-0x341e3" in the dialog,
On Mon, Aug 04, 2008 at 12:12:06AM +0200, Uwe Stöhr wrote:
> Andre Poenitz schrieb:
>
>> As a simple rule: both for Qt's translation system as well as for
>> gettext (used by e.g. LyX) plain ASCII (i.e. 7-bit-"clean") source
>> strings are strongle encouraged.
>
> But what we fill in the combo need
Andre Poenitz schrieb:
As a simple rule: both for Qt's translation system as well as for
gettext (used by e.g. LyX) plain ASCII (i.e. 7-bit-"clean") source
strings are strongle encouraged.
But what we fill in the combo needs to be translatable. So with an Arabic locale "„text“" will have
Arab
On Sun, Aug 03, 2008 at 11:32:49PM +0200, Uwe Stöhr wrote:
> I wanted to fix bug 5112 that we display the different quotation marks wrong
> in our languages dialog.
>
> According to the Qt documentation:
> http://doc.trolltech.com/4.4/unicode.html
>
> It works, when I use
> langModule->quoteStyleC