This very simple. Up to now, when I want to apply a bold attribute I just write "Bold" in the macro. However, when I change the language of my computer (from english to french), the names in the format menu are not the same and the macro doesn't work anymore. Also, sometimes I would like to make sure that the found expressions is neither bold or italic but there is no "regular" command in the format menu and the macro does not seem to find the commands in the tooldrawer. For me, it would be also useful to know how to apply "superscript", "subscript", "underline", etc. to a found expression.

But overall I am wondering whether you might not be better off working with (user defined) styles. The style names will be immune to localization, and you can easily change their definitions to get different results. You could keep the set of styles in a style library. It's very easy to import a whole collection of styles that way. Styles are also exclusive, which may be a plus (or a minus) depending on the situation.

I'm using a reading method for children that uses colors. I also use this color system with other texts and that is why I have made this macro (which saves me a lot of time even though it is far from perfect).

Hi again.
Here is an example of what I meant by trying to write the macro to Nisus' strengths. Instead of searching for each letter one at a time and then doing something, this macro looks at the letters one by one and then applies what is needed.

This macro works by first defining a hash, which associates each letter with a command. It then checks each letter and then carries out the command associated with the letter. I am not sure this is really a better way to do this, but it is another way.

Groucho wrote:I think macros should refer to menu commands as they are in English, no matter what localization you are using. Nisus might then provide a table with English commands and their localized names.

Do you means "…should be able to refer to …?"
The ability to refer to menu commands in the local language is just a given. I believe that the Nisus macro feature just passes on the menu command to the user interface. So as long as that command matches something on a menu somewhere then the command is carried out. That is why you can use a user defined macro/style/etc. as a macro command.

As far as being able to use English instead of the localized language, that is possible thanks to the "Localize" command.

What might be a nice idea however might be a sort of global "Localize". Imagine writing "Localize Start/End" before and after a block of menu commands (or at the start of a whole macro) and have it apply to all menu commands in the block (or macro).

phspaelti wrote:I believe that the Nisus macro feature just passes on the menu command to the user interface. So as long as that command matches something on a menu somewhere then the command is carried out. That is why you can use a user defined macro/style/etc. as a macro command.

That's exactly correct.

As far as being able to use English instead of the localized language, that is possible thanks to the "Localize" command.

Yes and no. The Localize command is very limited in what it can translated. It only translates phrases in the “localizable.strings” file found in the application bundle, which does not hold all menu command names. So while "Bold" is known, something like "Double" which one might want to use for the command Format > Underline > Double is not.

Also, some of the translatable phrases take an unexpected form, eg: instead of finding "Red" one must use "_Red". This last peculiarity should be removed, I'll file it as an issue for fixing, but it's something to be aware of.

martin wrote:Also, some of the translatable phrases take an unexpected form, eg: instead of finding "Red" one must use "_Red". This last peculiarity should be removed, I'll file it as an issue for fixing, but it's something to be aware of.

Indeed, I just had a look a this file. Is there some kind of logic behind why some terms have prefixed "_" ?

martin wrote:Yes and no. The Localize command is very limited in what it can translated. It only translates phrases in the “localizable.strings” file found in the application bundle, which does not hold all menu command names. So while "Bold" is known, something like "Double" which one might want to use for the command Format > Underline > Double is not.

So how does that work? Is the term "Double" not localized? I see that the file contains "_Double Underline" even though that does not appear on the menu. I guess my question is what this file really represents.

The "Localizable.strings" file contains phrases that NWP will display to the user. These might be entire sentences, like questions found in prompts, or small phrases used the undo menu or other GUI elements. The words "Double Underline" are used in the stylesheet view, as an attribute bubble. That underscore prefix is just to help us during development; if something appears in the GUI with an underscore, we know it isn't being translated properly.