XUnity.AutoTranslator
XUnity.AutoTranslator copied to clipboard
bbepis
Add Post-processing after regex
Could RegexPostProcessing be added (similar to RomajiPostProcessing, TranslationPostProcessing) that's run on translations that match an r: or sr:? TranslationPostProcessing doesn't apply if a network job isn't created, but I would like ReplaceWideCharacters to be applied.
Could you provide an example so I am sure I understand the use-case? I assume this would only be run on specific regexes are not globally?
I very much want it to be globally if the line matched an r: or sr: and it's enabled.
Given:
r:"^例([０-９0-9]+)$"=Example $1
I want 例０ => Example 0 if I have ReplaceWideCharacters enabled. (if that's non-obvious that was a wide ０ on the left)
Given r:"^([Ａ-ＺA-Z]+)型$"=Type $1
Ａ型 => Type A
Doing something like this for r:-style regexes is certainly possible. But sr: is much different.
First recognize that whatever is written in the text translation files should take priority. So if someone uses a wide-character there I would expect that to be honored.
But sr: regexes are splitting a given translation up and making an additional lookup for each part. That means the whatever the result of that lookup is should prevail. Often a lookup fails because the term is not present (such as when it is a number or a letter). In that case the plugin just returns that as a part translation.
I guess what you would want is that it is ONLY in this case this "post processing" logic should be applied. But in this scenario there is also the configuration option OutputUntranslatableText to handle. Under normal circumstances if that option is enabled the plugin is going to output just the number/letters as 1:1 translations. But if this is going to make sense that would have to be after this post processing IF the translation is a part of a regex.
I will have to consider if there are more potential features this might conflict with.
Yeah, that makes sense about sr:. Even having just r: support would be great, if possible.
Alternately, having it only work with named groups that are flagged (similar to _i) (_p for "apply post procesing" and in an sr: allow _ip for "only apply post processing").
That is also something I considered. From a practical perspective it is not much different. But it might have some inconsistencies because then I would say the same have to be implemented for normal regexes as well. And in that case _i makes no sense.