Exemplified menu entries for change case menu

[manv-afk]

Fixes #9339

We modified the Change case sub-menus and their corresponding tips (displayed when you stay long over the menu) to properly reflect exemplified cases.

I've simply changed the text visible in the sub-menus and their tips to match exemplified cases #9339.

Here is a screenshot of the modified sub-menus.

• Change in CHANGELOG.md described in a way that is understandable for the average user (if applicable)
• [/] Tests created for changes (if applicable)
• Manually tested changed features in running JabRef (always required)
• Screenshots added in PR description (for UI changes)
• Checked developer's documentation: Is the information available and up to date? If not, I outlined it in this pull request.
• Checked documentation: Is the information available and up to date? If not, I created an issue at https://github.com/JabRef/user-documentation/issues or, even better, I submitted a pull request to the documentation repository.

[ThiloteE]

To ease organizational workflows I have linked the pull-request to the issue with syntax as described in https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue

Linking a pull request to an issue using a keyword

You can link a pull request to an issue by using a supported keyword in the pull request's description or in a commit message. The pull request must be on the default branch.

• close
• closes
• closed
• fix
• fixes
• fixed
• resolve
• resolves
• resolved

If you use a keyword to reference a pull request comment in another pull request, the pull requests will be linked. Merging the referencing pull request also closes the referenced pull request.

The syntax for closing keywords depends on whether the issue is in the same repository as the pull request.

[Siedlerchr]

Have a look at the failing tests please and also the l10n https://devdocs.jabref.org/code-howtos/localization.html

[manv-afk]

Hello, I've used l10n for menu entries and try to fix test issues but I still have 2 problems :

• I don't know why Deployment / Create installer and portable version for macOS (pull_request) failed

• And concerning the test Tests / Unit tests (pull_request), it fails because of this test :
  @Test void keyValueShouldBeEqualForEnglishPropertiesMessages() { ... }
  This test just simply check that for each entry in l10n (english version) has the same key and value. This is not true anymore if I have to change these Strings like it's done for french version for example. Maybe I should just remove this test ?

[Siedlerchr]

The keys on the left and the values must be equal,

[Siedlerchr]

Suggested change

	Lower\ case=lower case
	lower\ case=lower case

[Siedlerchr]

You can ignore mac. It does not work on forks. The unit test fails because the left and right side in the properties file must be equal. This is for the english version. You don't have to change other localisation files

[manv-afk]

Ok ty for mac test!
Yes I know that the test failed because values and entries should be equal. But then I don't know how am I supposed to do to exemplifies menu entries ? In the french version (where it is already implemented), they have not the same values/entries.

[Siedlerchr]

The test only checks the English version because obviously for the other languages this cannot be equal. Translators can write whatever the right translations is.

[manv-afk]

Ok but where am I supposed to put the exemplifies menu entries strings if I can't put them in JabRef_en.properties like this ?

[Siedlerchr]

@manu-vaillant-afk You changed the right side (the values) of the properties. You now have to change the left side (the keys) as well in the en.properties file.

[manv-afk]

@Siedlerchr if I change the keys in en.properties file, I'll also have to change keys in all other languages properties files.
And also all the functions getName() with the new key in all casechanger formatter right ?

For example, in the file java/org/jabref/logic/formatter/casechanger/LowerCaseFormatter.java :
I'll turn this :
public String getName() { return Localization.lang("Lower case"); }
into this :
public String getName() { return Localization.lang("lower case"); }

Tell me if it's what you want and I'll make these changes.

[Siedlerchr]

Yes, you have to adjust the pieces in the code and the keys in the English properties file. You don't need to change the other language files

[manv-afk]

@Siedlerchr I've try it locally but as I was thinking, it's not working well.
It works well in english, but not in other language because the new keys (like "UPPER CASE" which is called in Formatter.java) is not present in other languages files.

For me, there is no reason to change these keys, I just think that the test is not very useful and could be remove ?

[calixtus]

This is why this test is only checking for the english language file consistency. This test is in my eyes very useful, as it checks for the language keys consistent to the language resources, as it makes the sources more easily readable und keeps our coding style in JabRef consistent.

You don't have to change the keys in every other language file, this is done by crowdin automatically and many users, who help us translate JabRef to many different languages.

[manv-afk]

@calixtus @Siedlerchr Ok now the test is successful, tell me if I have to change anything else !