some messages are still hardcoded in english

[rnveach]

CS still has some output events that are hardcoded in the code and are only in English. Some already have translations in message files, but we don't use them.
We translate check messages to their specific language so non-english users can understand the issue, we should do the same with every output of CS (minus XML attributes and such) so there is no confusion.

Examples:

checkstyle/src/main/java/com/puppycrawl/tools/checkstyle/DefaultLogger.java

Lines 130 to 143 in e18195d

	errorWriter.println("Error auditing " + event.getFileName());
	throwable.printStackTrace(errorWriter);
	}
	}
	@Override
	public void auditStarted(AuditEvent event) {
	infoWriter.println("Starting audit...");
	infoWriter.flush();
	}
	@Override
	public void auditFinished(AuditEvent event) {
	infoWriter.println("Audit done.");

checkstyle/src/main/java/com/puppycrawl/tools/checkstyle/Main.java

Line 192 in e18195d

System.out.println(String.format("Checkstyle ends with %d errors.", errorCounter));

TODO :

• AbstractAutomaticBean
• CheckstyleAntTask
• AbstractFileSetCheck
• SeverityLevelCounter
• AuditEvent
• FileText
• Checker (2 left)
• AnnotationUseStyleCheck
• FinalLocalVariableCheck
• IllegalInstantiationCheck
• MatchXpathCheck
• DesignForExtensionCheck
• AbstractHeaderCheck
• RegexpHeaderCheck
• CustomImportOrderCheck
• ImportControlLoader
• JavadocTagInfo
• InlineTagUtil
• AbstractClassCouplingCheck
• BooleanExpressionComplexityCheck
• RedundantModifierCheck
• NewlineAtEndOfFileCheck
• RegexpOnFilenameCheck
• SuppressWarningsHolder
• GenericWhitespaceCheck
• NoWhitespaceAfterCheck
• ConfigurationLoader
• DefaultLogger
• SuppressionsLoader
• SuppressWithNearbyCommentFilter
• SuppressWithNearbyTextFilter
• SuppressWithPlainTextCommentFilter
• XpathFilterElement
• MainFrameModel
• JavadocPropertiesGenerator not user facing, it is internal tool
• XmlMetaReader
• PackageNamesLoader
• PackageObjectFactory
• PropertiesExpander
• PropertyCacheFile
• SarifLogger
• ParentModuleMacro not user facing, it is internal tool
• PropertiesMacro not user facing, it is internal tool
• SiteUtil
• ViolationMessagesMacro not user facing, it is internal tool
• XdocsTemplateParser not user facing, it is internal tool
• TreeWalker
• AnnotationUtil
• CheckUtil
• CommonUtil
• JavadocUtil
• OsSpecificUtil
• XMLLogger
• XpathFileGeneratorAuditListener not user facing, it is internal tool

[romani]

example of translated exception:
https://github.com/checkstyle/checkstyle/blob/master/src/main/java/com/puppycrawl/tools/checkstyle/Checker.java#L320
https://github.com/checkstyle/checkstyle/blob/master/src/main/resources/com/puppycrawl/tools/checkstyle/messages.properties#L2

[subkrish]

@romani @rnveach Could you provide any other examples for translated messages?

[romani]

Why this example is not enough ? Please share your problem

[subkrish]

@romani I am having a trouble in trying to understand what class to import to use localized messages. I was trying to follow how localized messages have been used elsewhere. But due to different implementations, I wasn't sure how to implement it.

I just wanted a little more clarity.

[romani]

it is better to try another issue for you.

[subkrish]

@romani Okay but I give trying to solve the issue my best shot and if I fall short I'll work on a different issue.

[romani]

@subkrish , please proceed with hardcoded lines at:

• please investigate why DefaultLoggerTest is NOT failed in localized UTs, as "Error auditing" is hard coded in UT in English.
• Main
• Checker
• please recheck that non of Exception throw message is left with hardcoded content (152 cases as minimum):

~/java/git-others/checkstyle/checkstyle/src/main/java/com/puppycrawl/tools [master|✔ ] 
$ grep -R "throw new" .* | grep "\""
./checkstyle/PropertyCacheFile.java:            throw new IllegalArgumentException("config can not be null");
./checkstyle/PropertyCacheFile.java:            throw new IllegalArgumentException("fileName can not be null");
./checkstyle/PropertyCacheFile.java:            throw new IllegalStateException("Unable to calculate hashcode.", ex);
....

[subkrish]

@romani @rnveach Looks like the message for this

checkstyle/src/main/java/com/puppycrawl/tools/checkstyle/Main.java

Line 192 in e18195d

System.out.println(String.format("Checkstyle ends with %d errors.", errorCounter));

is not present in the 'messages.properties' file and the subsequent other languages files. Do I add them for the languages present and then remove the hardcoded lines? I might have to use a translator for the other languages messages.

[rnveach]

Do I add them for the languages present and then remove the hardcoded lines?

Yes.

I might have to use a translator for the other languages messages.

That is what everyone does. No one in Checkstyle of us know all these languages.
If translation is horrible, someone will make a request to have it fixed.

[subkrish]

@romani @rnveach for the Main file changes should also be made to command line option that only print in english right?
For example:

// show version and exit if it is requested
            if (commandLine.hasOption(OPTION_V_NAME)) {
                System.out.println("Checkstyle version: "
                        + Main.class.getPackage().getImplementationVersion());
                exitStatus = 0;
            }

and https://github.com/checkstyle/checkstyle/blob/master/src/main/java/com/puppycrawl/tools/checkstyle/Main.java#L614-L636

[romani]

no changes to CLI is required, behavior should be the same as Check messages:

• use default locale
• if no translations for default locale, use default (english)

[subkrish]

@romani @rnveach

please investigate why DefaultLoggerTest is NOT failed in localized UTs, as "Error auditing" is hard coded in UT in English.

After some researching, I found out that maven runs the test in a separate forked process.

Please look at this:

• http://maven.40175.n5.nabble.com/maven-surefire-plugin-and-default-locale-td121365.html
• http://maven.apache.org/surefire/maven-surefire-plugin/examples/debugging.html

[rnveach]

maven runs the test in a separate forked process.

But this is not affecting our other tests, right? Why is it just affecting these?
I am pretty sure I have seen locale tests fail before.

Ex:
#3377
#4003
#3989
#3896
And so on....

[subkrish]

@rnveach @romani

I tried running this command -> mvn clean integration-test failsafe:verify -DargLine='-Duser.language=de -Duser.country=DE' but DefaultLoggerTest didn't fail as it was supposed to because the message is hardcoded in the test:

assertTrue(output.contains("Error auditing myfile"));

But when the same option -> -Duser.language=de -Duser.country=DE is set in the POM file the test failed:

[INFO] Running com.puppycrawl.tools.checkstyle.DefaultLoggerTest
[ERROR] Tests run: 2, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.001 s <<< FAILURE! - in com.puppycrawl.tools.checkstyle.DefaultLoggerTest
[ERROR] testCtor(com.puppycrawl.tools.checkstyle.DefaultLoggerTest)  Time elapsed: 0 s  <<< FAILURE!
java.lang.AssertionError
	at com.puppycrawl.tools.checkstyle.DefaultLoggerTest.testCtor(DefaultLoggerTest.java:43)

I don't understand the difference between the two. I was assuming both give the same result, either UTs fails or passes.

EDIT: Looks like if the command is run as mvn clean integration-test failsafe:verify -DargLine='-Xms1024m -Xmx2048m -Duser.language=de -Duser.region=DE' then the UTs are failing as expected. I removed <argLine>-Xms1024m -Xmx2048m</argLine> from POM and then ran the command.

[romani]

@subkrish , good catch.

it is caused by fix for #4316 , I send PR to address it #4558 .

[subkrish]

@romani This means that now DefaultLoggerTest will fail as the messages are still hardcoded. I would need to make a new PR to change those UTs as well.

EDIT: I will make those changes first and then I suppose PR #4558 can be merged because the localized tests will fail as mentioned above.

[romani]

my PR is failed, that is good, please provide PR with fix for localized message

[subkrish]

@romani I have just created PR #4559 fixing those violations.

[romani]

@MANISH-K-07 , can you finish this issue for all other cases? after first PR , I think you can update all others in single PR, but you can do multiple, it is also good.

Please create list of classes to update to let us easily track what is left to do.

[MANISH-K-07]

@MANISH-K-07 , can you finish this issue for all other cases? after first PR , I think you can update all others in single PR,

@romani , I have absolutely no problem with closing this issue in a single PR (or atmost 2-3).

Although, please excuse me as I wanna ask you and @rnveach to re-confirm this.
a repeat of #14595 I would definitely not want :)

Please create list of classes to update to let us easily track what is left to do.

Sure, I will post a ToDo list shortly....

[romani]

I don't think you will repeat that massive update. You know all what is required to make this update, so it will be very technical and routine update for and us, as we already agreed on how to do this update.
In middle of update, if you feel better to split, we are always good with it.

[MANISH-K-07]

Pattern match gave me the following classes to update.
I am attaching the raw log in the comment below, but I will be hiding the comment coz its huge :)

TODO :

• AbstractAutomaticBean
• CheckstyleAntTask
• AbstractFileSetCheck
• SeverityLevelCounter
• AuditEvent
• FileText
• Checker (2 left)
• AnnotationUseStyleCheck
• FinalLocalVariableCheck
• IllegalInstantiationCheck
• MatchXpathCheck
• DesignForExtensionCheck
• AbstractHeaderCheck
• RegexpHeaderCheck
• CustomImportOrderCheck
• ImportControlLoader
• JavadocTagInfo
• InlineTagUtil
• AbstractClassCouplingCheck
• BooleanExpressionComplexityCheck
• RedundantModifierCheck
• NewlineAtEndOfFileCheck
• RegexpOnFilenameCheck
• SuppressWarningsHolder
• GenericWhitespaceCheck
• NoWhitespaceAfterCheck
• ConfigurationLoader
• DefaultLogger
• SuppressionsLoader
• SuppressWithNearbyCommentFilter
• SuppressWithNearbyTextFilter
• SuppressWithPlainTextCommentFilter
• XpathFilterElement
• MainFrameModel
• JavadocPropertiesGenerator
• XmlMetaReader
• PackageNamesLoader
• PackageObjectFactory
• PropertiesExpander
• PropertyCacheFile
• SarifLogger
• ParentModuleMacro
• PropertiesMacro
• SiteUtil
• ViolationMessagesMacro
• XdocsTemplateParser
• TreeWalker
• AnnotationUtil
• CheckUtil
• CommonUtil
• JavadocUtil
• OsSpecificUtil
• XMLLogger
• XpathFileGeneratorAuditListener

[romani]

Thanks a lot copied to description.
Looks like we need to enforce no string messages in exceptions by some Check. Any proposals ?

[MANISH-K-07]

Looks like we need to enforce no string messages in exceptions by some Check. Any proposals ?

Regexp, we could use.
We could design a check that throws violation when regex pattern "throw new" .*"Exception("\" is matched ?
This would violate any strings hardcoded in exception messages.

PS: the regex mentioned above might not be exactly accurate, I will frame a proper one if the idea is all good.

[romani]

Can we do xpath Check usage?

[MANISH-K-07]

Can we do xpath Check usage?

Well, I suppose we should be able to set a permanent query in MatchXpathCheck that runs parallely or smtg like count(/*/*/event[contains(@description, '"')]) and throw violation if count > 0.
The scope of this should only be our production files. So, I'm not sure if we would want to extend a feature like this to an existing check and reduce its scope ?

checkstyle/src/main/java/com/puppycrawl/tools/checkstyle/checks/coding/MatchXpathCheck.java

Lines 89 to 90 in 103d34f

	/** Specify Xpath query. */
	private String query = "";

[nrmancuso]

Can we do xpath Check usage?

Yep, regexp alone will be hacky and unreliable for this. We need a MatchXPath module that checks for string literal usage.

[romani]

The scope of this should only be our production files. So, I'm not sure if we would want to extend a feature like this to an existing check and reduce its scope ?

scope should be only main folder, and all not user facing classes, should be added to suppression. Examples: XmlMetaReader, *Macro, XpathFileGeneratorAuditListener

[romani]

@MANISH-K-07 , please rephrase a question, I do not understand it.

[MANISH-K-07]

@MANISH-K-07 , please rephrase a question, I do not understand it.

I don't exactly recall what my thought was back then.. Will brush up a bit and follow-up on this..
From what I understand, the fix for this is rather simple as mentioned at #3110 (comment) and #3110 (comment)

However, could we do new module for this after all existing strings are updated?.. to avoid extra suppressions
I will get on this issue after proposal submission dates