#926 Make Regular expression for custom tags project-specific

[Roman Mironov]

1. What is a custom tag in one project is not necessarily an untranslatable in another project.
2. This will allow sending a project to a team member with this option already configured instead of asking that team member to configure it manually.

This request is similar to Kos's [#824] "RegEx for fragments that should be removed" per project, which I also second.

[Kos Ivantsov]

[#824] can be merged with this one, I think.

And won't it be easier to implement this RFE if project-specific RegEx for custom tags and text to be removed were used in addition to global ones. I know very little about programming, but I think that if both project-specific and global RegEx are checked rather then only one of the two, it should be relatively easy to add two other parameters to the whole tag validation thing, and not to rewrite that part. But that is just my layman's perspective, and things might be much more complicated in the reality. I also include two GUI mock-up images to illustrate how I see it. If they are not helpful, maybe they at least can be entertaining. If not, then I've really screwed it up, sorry.

[msoutopico]

Adding my brief two cents: For the sake of consistency, I think it would make sense for project-specific custom tags to work just as segmentation or filters work: if there's a project-specific config file, that's the one used, rather than the global setting. However, probably it's very easy to merge the two regular expressions: (foo|bar) + (baz|zoo) = (foo|bar|baz|zoo) or ((foo|bar)|(baz|zoo)).

[Kos Ivantsov]

And an afterthought. In the Tag Validation dialog those proposed and mocked-up check-boxes to include project-specific RegEx can be omitted (thus leaving the dialog as it is right now). One can just leave appropriate fields empty, and Tag Validation should always check *both global and project-specific sets of these RegEx'es.

[Héctor Cartagena]

+1

[msoutopico]

I think I could find funding to sponsor this development. Quotes welcome.

[Jean-Christophe Helary]

Project specific settings can be accessed from the command line.

[msoutopico]

Hmm, why is this comment related to this ticket?

[Jean-Christophe Helary]

Creating project specific custom tags is as easy as accessing a configuration folder with the relevant custom tags defined there.

[msoutopico]

If you are referring to launching OmegaT from the CLI with the --config-dir argument (or something like that) to use a specific config folder where custom tags are defined (in omegat.prefs), that is not equivalent to the feature proposed in this ticket, and does not meet the needs behind it.

Specifying a config folder with a command line argument might be a valid workaround for a user who is happy to maintain different config folders for different needs, but it is not a solution when you want to have a project that your users can download, unpack or open in OmegaT (GUI) and that already has correct custom tag definitions specific to that project and regardless of the custom tag definitions specified in the user preferences (regardless of whether they come from the default config folder or from a specific custom config folder).

It's the same logic as with project-specific segmentation or filters. You might use a custom config directory with the --config-dir parameter, but OmegaT will use the project-specific segmentation rules and filter settings, if the project has them, and not the generic ones from your config folder just because you're using a specific a custom config folder.