Added Locale.ROOT to toUpper/toLower Methods #2584
Conversation
| @@ -65,10 +66,10 @@ public int compare(BibEntry e1, BibEntry e2) { | |||
| // sorted according to last name. | |||
| if (InternalBibtexFields.getFieldProperties(sortField).contains(FieldProperty.PERSON_NAMES)) { | |||
| if (f1 != null) { | |||
| f1 = AuthorList.fixAuthorForAlphabetization((String) f1).toLowerCase(); | |||
| f1 = AuthorList.fixAuthorForAlphabetization((String) f1).toLowerCase(Locale.ROOT); | |||
There was a problem hiding this comment.
We can only use ROOT for language insensitive Strings. We think not all missing places are insensitive. Also, sometimes Locale.ENGLISH or so might be better in such cases?
There was a problem hiding this comment.
Hm... Generally, I think ROOT is better than ENGLISH for Strings where we use them internally, e.g. to match files names etc..
However you have a point. If the String is language sensitive it might be better to use the user-specific Locale (i.e., the Locale.getDefault();). However in this case we must be sure that it is not used for any comparisons etc., because this would break stuff if compared to Strings that were manipulated with another Locale.
There was a problem hiding this comment.
In general we should use ROOT for internal strings only. And especially in reading/writing we have to be backwards compatible.
For GUI stuff we should use the English locale for english terms, e.g. the bibtex fieldnames or entry types.
As this effects many cases. I think we should discuss this in a devcall @JabRef/developers WDYT?
There was a problem hiding this comment.
Is there any issue solved with this?
Is it worth that we spend two hours on this? Why?
There was a problem hiding this comment.
I'm in favor of merging this PR at is right now. I can't see any disadvantage of using ROOT instead of the default one. Maybe for some GUI related stuff you can argue about ENGLISH but well...The worst possible thing (from what I get) is that now the keys of some entries with "strange" values change and maybe the order in the main table is slightly different...not very system-critical.
LinusDietz
changed the title
|
I have thought about this matter for a while and would argue to merge it as it is.
|
LinusDietz
changed the title
LinusDietz
added
the
status: ready-for-review
|
Please do not underestimate the value of UTF-8 and the power of biblatex to handle UTF-8. My personal bibliography is handled in UTF-8. Now LaTeX encoding any more. When I use it at Springer papers, I use our converter to convert to plain latex. See http://help.jabref.org/en/CleanupEntries. See also #160 :) |
|
Yes, biber + biblatex all handle stuff in UTF-8 and I think the default for a new db is already UTF-8. My dbs are also all in UTF-8. No more Latex encoding. And here we should be aware of a sort order depending on the locale. |
|
Ok, then let's forget about the encoding point, even if it unclear how many people actually use a bibliography compiler that supports UTF-8... |
|
After resolving the conflicts, it is OK for me to merge. We will fix wrongly uppercased things when issues will come up. |
koppor
removed
the
status: ready-for-review
This can improve the robustness JabRef for users with `exotic' Locale settings. See https://docs.oracle.com/javase/8/docs/api/java/lang/String.html#toUpperCase-- .