What's i18n message key string case style is recommend?

[Bob Du]

What's i18n message key string case style is recommend?

I've reviewed the current i18n message key string case style conventions.
In the core, it is already in a very chaotic state.
Not to mention in various plugins.

some file use PascalCase
like: core/src/main/resources/hudson/cli/Messages.properties

some file use camelCase
like: core/src/main/resources/jenkins/console/Messages.properties

some file use snake_case
like: core/src/main/resources/hudson/model/Cause/UserIdCause/description.properties

some file even mix under_score and CamelCase naming conventions.
like: core/src/main/resources/jenkins/install/Messages.properties

If there were no previous conventions regarding this matter, can we reach a new consensus on which naming style to use in new files?
To be honest, every time I need to add a new message key, I hesitate for quite some time.

PS: I'm not trying to blame anyone. I just hope we can do better going forward.

[Mark Waite]

I believe there were no conventions previously because the initial default is to use a form of the original message text as the name of the property.

I prefer the camel case format because the properties are fields of their associated Messages class in Java.

 

I prefer to not change the existing property names due to the risk of mistakes and surprises from that type of renaming exercise.

I'm open to other ways of thinking

Mark Waite

[Bob Du]

I fully agree with your preference for using the camel case style for i18n message keys, and I also support not migrating existing keys to avoid unnecessary risks and disruptions.

At the same time, I wonder if we could go one step further and formally recommend this approach for future development as part of a Jenkins style guideline. Specifically, could we suggest that new plugins or files, or those with mixed/chaotic existing conventions, should adopt camel case for new message keys? This would provide clear guidance for contributors and help reduce hesitation or inconsistency when adding new translations.

https://www.jenkins.io/doc/developer/publishing/style-guides/


If a file/module already uses a consistent naming style (whether camelCase, PascalCase, or snake_case), continue to use that style for new keys in that file/module.
If developing a new plugin/module, or if the existing file has mixed or inconsistent naming conventions, use camelCase for any new message keys.
Large-scale renaming of existing keys is not recommended, to avoid compatibility issues.