Oleksandr Moskalenko wrote: >That way >your English, German, Russian, Japanese, or whatever shop could define the >formatting elements in their native language to make it easy to create markup >that their local authors would be willing to adopt consistently. Then, they >provide a conversion table and all import happens transparently from then on. > > This is exactly what I was referring to with regards to "domain specific markup." Not only language, but document purpose and publication type are factors. A German weekly newspaper will have different needs to an English weekly newspaper, which will have different needs to an English monthly magazine with world-wide one-off contributors, which in turn will have different needs to a quarterly technical journal.
In my view it's not a matter of having one GetText plugin and one fixed "Scribus" markup, but using the power of that interface to create the markup you need. This might be done with one very flexible/configurable plugin, or by customising a plugin to your needs. That's not to say there's no place for a Scribus-specific text markup (on the contrary, for things like that external subediting tool I was talking about, it'd be crucial), only that there's a useful place for domain-specific markups too. I know some magazines use their own custom markups already, sometimes hand-formatting them after import, and sometimes doing it automatically. Making this easier wouldn't be harmful at all... and the GetText interface is a good way to get into Scribus development. *hint*. *hint*. -- Craig Ringer
