[Mr. Data]

This, finally, leads me to the point where I want to emphasize that we need more support. But in saying 'more support' I don't mean updates of language templates every other day. I mean a way of enabling us to do things that makes our work easier and at the same time frees you from being bothered all the time keeping you away from what's really important to your further development of REAPER.

An Example:
I'm sincerely in doubt that REAPER should look like this in pending or future versions, just because they're not in English.


I'm sure you're quite clear about which one of the colored lines refers to which element types anchor point to emphasize (mis)'alignment'.
compared to:


Yes. this looks nice and tidy compared to the above version, doesn't it?
And why shouldn't it look the same in other languages?
Imho even more as we are moving on to a new full version number. (I think it's 6, isn't it?)

In post #301 I already made a proposal, how this could be managed, but I came to the conclusion that this can't work, because there can be elements in a dialog that hold no text.

Maybe an IDE could be a solution to this problem, where we have an editor to place elements of a dialog aligned.

The AutoHotKey package, for instance, includes a tool called "SmartGUI Creator", which is designed to create or alter dialogs.
There is also a built in function that allows to 'steal' dialogs from other software that then can be edited. It works like this:


This comes quite close to what I'm up to.
The drawback is that this tool only works with standard Windows elements such as BUTTON, COMBOBOX or EDIT, but not with special things like "REAPERknob".
Also it grabs only elements that are visible at the moment of grabbing. So in the above window the element "[modified]" is missing, although it belongs to the dialog.

So I ruminated a little how this could work and how this could be included in the langpack. As I mentioned already an IDE would be handy, preferably one that allows to move and resize elements in a visual way, as in 'SmartGUI'.

In the following I've botched up something that shows how such a structure could look like when it is shown and edited in an IDE.
On the right hand side of the IDE editor, there could be a list of all dialogs from which one could select one to work on.

As an example I'll stick at the Crossfade editor, 'cos this is extremely messy imho and includes some special elements.

When having chosen a dialog from the list (522 in this example) it could present itself in the editor like this (along with its visual representation):




The CAPTION, as well as all other elements, containing strings, could hold either these strings in double-quotes or their hash numbers, which in the best case would be filled in automatically if they exist in the langpack.

The LAYOUT term, followed by '5CA1E0000000000x' can determine the layout number for the following block, since, depending on wideness and height, there can be different layouts as it is in the Crossfade editor respectively the Item properties dialog and some others.

The '5CA1E' command is a great help - beyond question - nonetheless it has two big disadvantages: When using it, it (1) resizes all elements in the dialog, making it necessary to oversize quite a number of them to keep everything readable, while at the same time (2) ruining all alignments. So, if the langpack interpreter would find another value than 0 at the last digit of '5CA1E', it would know, there exists a special formatting block. And when needed, there could be more than one block if e.g. the dialog is rezisable, hence having more layouts, as it is shown at the bottom of the mockup. A resizing factor would either be obsolete in such cases by determing last digit 1 = normal dialog, 2 = double width, 3 = double height or 4 = special cases or giving one of these numbers with a factor (e.g. "5CA1E00000000002=1.0 2.0" for double height).

Also, in the above mockup I tried to emphasize which flags are allowed to be changed (for formatting reasons e.g.

CONTROL STATIC, SS_LEFT, "Volume:", 14, 186, 26, 8

and which are not, but still shown, to make it easier to know, on which element one works.
So, for instance...

CONTROL BUTTON, BS_PUSHBUTTON, 42, 61, 39, 20

could let you change coordinates, but not the kind of the element.

In addition to that I colored hash numbers opposed to strings for better distinction.

Finally special REAPER elements, like 'REAPERknob' are yellow colored.

It would also very handy if strings in dropdown menus could entered here directly, since they are not in the dialog structure themselves, e.g. as in:

<
 CONTROL STATIC, SS_LEFT, "Preserve:", 234, 152, 31, 8 
 CONTROL COMBOBOX, CBS_DROPDOWNLIST, 267, 149, 42, 30 
 <
  3BEB0AE437FA2F12 ; (center)
  1B262DDE53BE63B5 ; (start)
  0DBD7F7EE933458C ; (end)
 >
>

... or ...

<
 CONTROL STATIC, SS_LEFT, "Preserve:", 234, 152, 31, 8 
 CONTROL COMBOBOX, CBS_DROPDOWNLIST, 267, 149, 42, 30 
 <
  "center"
  "start"
  "end"
 >
>

What isn't covered here is the distinction between

A037BD54A635ACF8=Editing 1 crossfade
C1BDF555F6EEBD1D=Editing %d crossfades

...and the string

"Editing 0 crossfades"

...which is in the dialog structure, since I don't know, how this is handled.
Same goes for the bitmaps, showing the transport buttons, since they don't appear in the structure.

Whether these structures should go into the langpack file itself or a separate file or even in a separate file for each dialog, I'm not clear about yet, but I tend to the langpack file itself.

All of this is just a proposal how things could be made, and when comparing the US-English dialog...


...with an equally tidy localized German one...


...wouldn't it be reasonable to make these things at least possible for REAPER v6, so we all could work with REAPER in the same charming way as native (US) English speaking/reading people can do, instead of having all those messy dialogs?
(As a sidenote: Did you notice that in the not localized version some values are not completely visible, but in the localized they are? (See 'Contents:'))

(BTW: Wouldn't such an IDE be a good idea for WALTER themers as well?)

I know that this increases the demands of work to put into this a lot, but I've no doubt that there are people who are willing to take the pain to do it. And this, although all this doesn't do anything to the functionality to REAPER at all. On the other hand it would be the advantage that noone needs to go that far, but at the same time can do if (s)he wants to.

I'm curious:
Isn't there a way to make all strings that need to be translated or are part of translated strings make accessible once and for all, except a few, like the license thingies e.g. in one go?
Isn't there a way to rule out the issues with special characters like 'ö' (ö), 'ä' (ä), or 'ü' (ü) or others used in other languages out of the way permanently, so all of us (including you) don't have to bother with this anymore?
I also often encountered problems with strings that begin or end with 0x0d 0x0a, which the online calculator doesn't handle, hence giving incorrect results.

Maybe this should have gone into the feature requests thread, but imo this is not a feature, but rather a suggestion to get progress to localization itself which is already a feature.


-Data