[Date Prev][Date Next][Thread Prev][Thread Next][Thread Index]

Re: [XaraXtreme-dev] String lenght in forgein languages


Remember that the truncation of text depends on the font size too, not just the size of the controls in dialogs.

I have my desktop font set to 8pt Bitstream Vera Sans and I don't see any truncated messages. This setting seems to make the whole desktop look more professional (personal opinion, I know) and may be a workaround you can use if truncated text is annoying you.

BTW: Sizer-based dialogs are going to need careful design to ensure they look good in all the possible permutations...


Tobias Burnus wrote:


Séverin Lemaignan schrieb:
I'm still on the french translation, and a small issue appeared : some
strings are much longer in french than in english, and are sometimes
cut. It's particulary the case in the "Options" dialog, which is not
resizable (cf attached screenshot). Can you do something about it ?
Well, there are even strings in English which don't fit.* I asked a
similar question and Alex answered them (quoted at the bottom of this
In a nut shell: The majority of the dialogs has a fixed pixel size.
There are plans to convert them to to use "sizers", which makes them
resizable and removes this clipped-text problem.

(* Example: "File|Page Options..." -> "General" dialog has also a
clipped string in English: "Make groups be transparent as a whc")

Maybe the following is also of interest: Alex's answer to my translation
In addition, I think one really needs some documentation regarding the
translations, i.e. what to translate and what not.
I'd like to see some general information e.g. for

msgid  "&Blank Tool;Activate the blank tool;Blank"
msgid "&About Xara XS;Information about Xara XS ;AboutOp"
msgid "XYZxyz"

What to translate and what not? And what means the third entry after the
Yes indeed. In answer to your specific question, the first is
the menu entry, the second the help entry, and the third the
OpToken of the OpDescriptor it invokes (i.e. the internal command
it is attached to). Do not translate the third one :-)


Alex wrote on 9 June:
The windows at the moment are straight imports of the Camelot dialogs,
i.e. they are (with a couple of exceptions) non-resizable with pixel
settings. They are autoconverted by a tool (rc2xml) periodically
be me.

However, xrc supports resizable dialogs constructed using sizers
(see the wxWidgets site for details). Ultimately, the dialogs need
to be converted to sizer based ones. There are GUI tools to do
this (e.g. DialogBlocks) - though there are some problems using
them (see below). If you try fiddling with the colour editor,
for example, you will see it is resizable. Message boxes do this
too, as does the bitmap preferences dialog.

Ultimately, all the dialogs need to be redesigned with sizers, not only
to support translations for languagues with (typically) long words
(e.g. German) but also for shorter ones (e.g. Japanese), and for
different fonts. As you have discovered, sometimes the linux font
just doesn't fit (though I am thinking of manually specifying the
point size in dialogs like we do on bars).

If you would like to help redesign the dialogs we would be very
grateful. You don't need to know anything about the internals of
the program provided you keep the xrc the same, and you can
(in general) just import the controls and adjust them so they
autosize. But you do need to understand a bit about sizers.
Fortunately a GUI editor lets you experiment with them.
One problem we have at the moment is annoyingly DialogBlocks
(permanently) strips out and junks crucial info about any
classes it doesn't understand (e.g. wxOwnerDrawnComboBox -
that's all combo boxes and wxCamArtControl - that's all
bitmap buttons). So these need to be reinserted manually. This
is a complain pain in the rear end and as far as I can see
there's no need for DialogBlocks to do it, which makes it a less
than useful tool right now for any dialog redesign because
you have to manually re-edit the .xrc afterwards - on the
colour editor the sizer design took about 10 minutes and
rebuilding all the stuff DialogBlocks dropped on the floor
took about an hour (but that is a complex dialog).
I don't know if any of the others suffer from this. If this
were fixed, dialog design would be 100 times easier. I
don't know whether other tools suffer from this problem.