[zanata-bugs] [Bug 1200208] Cannot enforce Java variable validations in Zanata's translations due to false positives

[bugzilla at redhat.com]

https://bugzilla.redhat.com/show_bug.cgi?id=1200208



--- Comment #9 from Sean Flanigan <sflaniga at redhat.com> ---
(In reply to David Mason from comment #7)
> (In reply to Sean Flanigan from comment #5)
> > I think we should fix the bug simply (no need for story points), so that it
> > works properly for Java variables and ignores "{sometext}" (as used in
> > Python frameworks?).
> > 
> > However, if we want to have another validator that does work for variables
> > like "{sometext}", I think we should treat that as an RFE (with story
> > points).  Support for such variables is out of scope for the Java variable
> > validator, so we shouldn't let it increase the cost of fixing the bug. 
> > Right now we don't even know what to call those variables.
> 
> There will be a performance cost if we simplistically separate out these
> validations, due to iterating the same strings more times. We should look at
> separating the concept of a validator (the class that parses a string) and a
> validation (a specific thing that is checked).

Okay.  I was using validator the way a user might, meaning the thing they turn
on and off, but I probably should have said validation.  I agree that how the
various validations are implemented (one or many classes) is an implementation
detail which the user shouldn't have to care about.

>  - A validator would provide a set of validations, each of which can be
> turned on or off independently. e.g. what is currently presented to users as
> the java variables validator would instead appear to them as validations for
> "java variables", "django variables", "log4j variables" and anything else
> that makes sense to detect in the same single-pass over the string.
> 
>  - Users should not have to care which validator implements each validation.
> Either show all validations without any grouping, or make sensible groupings
> that do not depend on the implementation details.

Right.  But I think the performance problem can be handled fairly well with
your other suggestion, some sort of  cheap 'isSupported' method.

My point, though, is that we shouldn't let the possible need for a python
{sometext} validator to get in the way of the very real need for a reliable
Java {0} validator.  If both validators were implemented 100% to spec, I doubt
they would share much code anyway.  They both involve open/close curly braces
"{}" but they may not have much else in common.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=1kBtZe9N88&a=cc_unsubscribe