Voting starts in March for the Drupal Association Board election.
This patch removes *all* the custom one off code for config translation of date formats because locale module already handles that perfectly for *shipped* date formats. Config translation has auto generated UIs that cover both shipped and custom created config. We can improve DX by removing the customized solution here and reusing the system provided one.
TL;DR: Drupal 8 has two competing built-in user interfaces to localize date formats. None of them actually allow you to translate/localize formats. Then there is a third one that allows localization but is very hard to use and only works for shipped formats. The combination of them works even worse.
Let's see what they can do:
Can localize both on the edit tab and on the localize tab! "Localize" is named in a non-standard way also, nowhere else do we use this label for this task.
If you go into Edit, you can actually associate multiple languages with a format. That sounds cool in theory, but if you want different value for a language, you cannot enter that. Also you cannot save the same machine name with a different value for a different language, so no way to *actually* localize your date format. You can just declare which languages a format applies to (which then is not really used to eg. exclude formats from a list or things like that AFAIK). The different languages are also saved as translations, which directly works with locale override files crossing over to the concerns of that module:
So you want to actually localize your date formats! Go localize tab! Lots of promise here! :)
Cool, let's localize to Hungarian then! As you can see this screen is not that bad, it displays even hidden date formats, and lets you assign different values to them per language. At least that is the promise. Problems incldue no freeform picking, so eg. no way to actually localize in a way that would fit the Hungarian date formats. Also, no way to translate the label of the date format name which could show up on eg. a content submission UI. Also, this form actually does not work, it does not save the localized value. Why? Well, the key is in system_date_format_localize_form_save() and the submission function calling it. The relation of formats and dates is *very confused*.
The reason this screen works as it is is because in Drupal 7 you added formats and then paired formats with languages. So you surely had the right formats in this dropdown because it was coming from a pool of formats you entered. This actually works off of the main date format list now, which is confused. If I'd need to add the "Hungarian full date" as a separate high level format, that will show up alongside the "General full date" when selecting formats for date fields, display modes, etc. while we want the translations to kick in based on languages.
Let's imagine this screen would fulfill its promise and save those localizations somehow. So let's imagine we fix this page. Then, when you go back to the date format edit page, what would that show. Would it show it only applies to some languages and then the rest is edited on the localization page? That would not work for now either because the locale is not even removed from the format, so the next submission of the original form will overwrite your localizations.
Finally, also sincecore now exposes the date format default configuration for community translation, so localize.drupal.org can feed the Drupal site with default date format localizations. That is amazing. Also the third built-in UI for localizing date formats due to that became the locale module UI. That actually allows to translate both the date format string and the date format label. But only for shipped date formats, not for new ones added on the UI. That works for the use case of free-form picking of date formats but is pretty darn hard to use, since there is no help (eg. precalculation of how the format would show like on the edit form) and the date format gets no context:
Now imagine you translated something here, how is that compatible with the other UIs? Well, it is not. The translation entered here will work so long as you don't resave the format on either of the other two screens above, which both will overwrite the translations (in different ways). So the two above UIs actually work against being able to use the community provided date format translations :/
Remove both date locale user interfaces and their underlying trickery. Let locale module handle the date format translation as it already does thanks to. As for a nicer user interface, includes a far superior user interface for date format translation (has free-form input, date format previews and allows translation of date formats + integrates with the localize.drupal.org pre-translation pulling nicely). No overwriting on one UI the data that was entered in a different UI. Also that UI is fully autogenerated based on config schema and configuration entity information, so almost no special code required to do it there. Only the date format preview needed special code. So we can remove lots of one-off code and get nicely generated screens that are better. What's not to love?
The config translation module already has this autogenerated listing UI for date formats (and other types of config entities similarly as well):
Once you pick a language on the translate page where the buttons lead, you can localize the format free-form with live preview and even translate the format name. And once again this works well with locale module's feeding of translations from localize.drupal.org too.
This translation page is also wired into the date formats listing page as a Translate dropdown operation so not needed to go to a different UI even to translate:
User interface changes
Two useless interfaces removed.
|#17||interdiff.txt||1.2 KB||Gábor Hojtsy|
|#17||remove-bugos-conflicting-date-format-localization-17.patch||30.45 KB||Gábor Hojtsy|
PASSED: [[SimpleTest]]: [MySQL] 59,977 pass(es). View
|#15||interdiff.txt||1.33 KB||Gábor Hojtsy|
|#15||remove-bugos-conflicting-date-format-localization-15.patch||29.25 KB||Gábor Hojtsy|
FAILED: [[SimpleTest]]: [MySQL] 59,922 pass(es), 13 fail(s), and 5 exception(s). View
|#12||remove-bugos-conflicting-date-format-localization-12.patch||27.92 KB||Gábor Hojtsy|
FAILED: [[SimpleTest]]: [MySQL] 59,452 pass(es), 15 fail(s), and 5 exception(s). View