Sorted language keys alphabetically

[stefan-kolb]

As we have little context grouping i was thinking about sorting the keys alphabetically, so

• Words that should be translated consistently are close to each other
• translations are easier to find

Not a big deal but im putting this up for discussion.

[koppor]

Currently, there are logical groups inside the language file. Not everywhere, but sometimes.

Because of "Words that should be translated consistently are close to each other" and because Words can also stay in the middle of translations, I vote for keeping the order in the language file.

The decision to have the ordering of the English file was taken in the context of #1933.

Alphabetical ordering can be achieved by

• Using IntelliJ's alphabetical sorting functionality:
  

• CrowdIn
  

I agree that at first, alphabetically sorted files look "finish" whereas our current state seems to be confused. However, offering the possibility of the English file to be grouped, offers us to keep connected terms togeher.

See for instance "XMP metadata". It should be without hyphen in English (reviewers fault). Moreover, it is also translated differently in German. If these entries were kept together, the fix would be more easy!

Create\ entry\ based\ on\ XMP-metadata=Eintrag aus XMP-Daten erstellen
Do\ not\ write\ the\ following\ fields\ to\ XMP\ Metadata\:=Folgende Felder nicht in die XMP-Metadaten schreiben\:

Note in this example the term "XMP-metadata" appears NOT at the beginning, so alphabetical sorting destroys the connection between the translations.

I agree that these groups have to be created. Our tooling is ready to support us with the grouping, since our localization script sorts the non-English keys in the order of the English ones.

Other localization relevant PRs:

• Rewrite localization script #2010
• Fix localization task hints #2031

[tobiasdiez]

+1 for alphabetic order. For me personally, the ordering is only relevant in one case: when one removes a localized string from the code and the corresponding language key has to be removed from the English file. This is easier with an alphabetic order.

Logical groups are a nice idea in principle but a) they are not really present right now since all new translations are almost always added at the end of the file b) it is more work to maintain the groups c) they only have diminishing returns in my opinion.

[koppor]

@JabRef/translators, what do you think? You are the ones wanting high-quality translations. Do you care for grouping to be able to check for consistency easily?

[koppor]

@tobiasdiez My XMP example shows that grouping would have helped to a) spell "XMP metadata" always as such in English keys and b) ensure consistent translation. I know that currently no one volunteers to reorder the file, but enforcing alphabetical ordering removes that option completely.

[koppor]

Having a grouped file also offers the possibility to have the Menu entries first (they are allowed to contain & menu shortcuts= and the other language keys else. How can we otherwise check for invalid characters in the language keys?

[stefan-kolb]

If we would group it, we have to enforce that this grouping is kept consistent, which means:

• Every developer needs to find the right group for the translations (Not easy)
• Every Reviewer needs to be aware and check this for the language files (even harder)

My reasoning is - all of your arguments are valid and nice - but simply won't happen. Therefore, I think sorting the stuff from time to time would be neat.

But I have no strong opinion here as it doesn't matter that much.

[Siedlerchr]

Well, for the maintable beta branch, we no longer need the menu keys with & signs.
And often translations are reused, so the context is not always valid.

[mlep]

For me grouping is unimportant: using Crowdin, and carrying out the translation often, untranslated keys are "naturally" grouped.
Grouping may be helpful for a new language. However, it will always remain difficult for some strings to get the suitable translation without the context. A full (approximate) translation will be improved later on by using JabRef.

[koppor]

@Siedlerchr How do accelerator keys work then? How can I define the accelerator key for the translated keys? Think of &File vs. &Datei? Meaning: Alt+F opens the file menu in English JabRef and Alt+D the same menu in German. How can I (as developer) pre-configure that?

[Siedlerchr]

Ask @tobiasdiez

[tobiasdiez]

https://stackoverflow.com/questions/24499500/javafx-menu-first-letter-underline-decoration

[koppor]

I see, I am the only one. I will keep my sorted translations and merge updates manually back.

I will try to work together with @Brainsucker92 to be able to have JabRef_en-grouped.properties locally being synced with JabRef_en.properties (the corresponding JabRef_*-groupes.properties will be created accordingly). In that way, we can have both: the alphabetically ordered, where you all guys are working with and the grouped one, where I intend to work with. The -grouped.properties is for a quality day once a year. New keys are sorted into the groups, keys are reviewed for consistency, and languages we know will be reviewed for consistency, too.