Add a more descriptive path when Directory cannot be found

[devjuliet]

Issue problem: When you try to download a pdf (Lookup -> Search full documents online ) and you don't have a file directory set, an alert tells you that you should follow a path to set your file directory: Preference -> File. But that path is not correct because to set the file directory you need to follow this path: Options -> Preference -> Linked Files -> Main File Directory

Suggested changes: change the message to: Main file directory not set! Check the Preferences (Linked files) or the Library properties.

Screenshots:

Fixes #7197

• Change in CHANGELOG.md described (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 documentation: Is the information available and up to date? If not created an issue at https://github.com/JabRef/user-documentation/issues or, even better, submitted a pull request to the documentation repository.

[Siedlerchr]

Please see https://docs.jabref.org/setup/databaseproperties#override-default-file-directories
You can define relative directories in the library properties and thus the main file directory can be empty. In addition there's a checkbox to always use the bib file location which will override all other settings.

suggestion

change the message to No file directory set or. Check the preferences (linked files) or the library properties

[Siedlerchr]

It's better and easier for the translators if you put this in one string. See https://devdocs.jabref.org/getting-into-the-code/code-howtos#using-localization-correctly

[koppor]

We should also take care about casing - maybe less is better?

Main file directory not set. Check the preferences (linked files) or the library properties.

[devjuliet]

Great! I'll work on it

[devjuliet]

Changed to one string and also changed the message 😄

[Siedlerchr]

Thanks! Now you need to add this to the resources/l10n/en.properties file as well (see the LocalizationConsistencyTest) under l10n.
When the key contains spaces, you need to add a backslash after the word before the space. (see the other entries in the file)

[koppor]

Now the test fail complaining that a newline is illegal - see: https://github.com/JabRef/jabref/pull/7232/checks?check_run_id=1618423949#step:6:122

java.lang.RuntimeException: Main file directory not set.nCheck the preferences (linked files) or the library properties. contains a new line character. As this is a localization key, this is illegal!

You can try with <br> or <p> in the localization - such as other localizations did. Could you please try and report back?

[koppor]

BTW: Hint: How to read error outputs.

1. See the red crosses
   
2. Experience in JabRef tells: Click at Details at "Tests / Unit Tests"
3. Experience tells to scroll up, until one sees a red "Error"
   

Then try to understand the error message. I tried to explain the error message at my last commit. My wish, however, is that I am not the only one knowing how to click on "Details", scroll up and find "Error"

[Siedlerchr]

You can try with
or

in the localization - such as other localizations did. Could you please try and report back?

javafx no longer uses html, so \n is correct

[koppor]

@Siedlerchr May I ask whether you've seent he screen shot error output? Here the deep link to the method throwing the exception:

jabref/src/test/java/org/jabref/logic/l10n/LocalizationParser.java

Line 287 in afdb194

throw new RuntimeException(languageKey + " contains a new line character. As this is a localization key, this is illegal!");

It throws an exception if \n is contained there. Thus, we cannot use \n. Since you say that <p> and <br> cannot be used, we cannot have any newlines any more. Am I right?

[devjuliet]

Thanks for the review! I added some changes 😀

[Siedlerchr]

Thanks, looks good to me now!

[calixtus]

Huh, I think we totally forgot your PR when thinking about the issue with #7279. But since your PR is now independent of this issue, I don't see any cause not to merge, since every other remark is implemented.
Sorry for the delay and thanks for your work!