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

[Tobias Burnus <burnus@xxxxxxxx>]

Salut,

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
email).
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
question:
>> 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 "CAMELOT_BUTTONBAR"
>> 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 :-) 

Tobias


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.