Untranslated string in core but not on localize.drupal.org

retagging

This issue is reporting two problems which should be in separate issues. It makes this harder to review.

I tested problem #1 on Drupal 9.4.x, I did a standard install in German and the install screen no longer contains English text on the left side. So, that has been fixed.

However problem #2 still exists. Drupal core showed unstranslated string for German but on localize.drupal.org there no untranslated strings for German. I would think this is a problem on localize.drupal.org but I don't really know.

The Issue Summary needs an update, and using the standard template will help. I think that everything about problem #1 can be removed and rescope this to address problem #2. A change of title would also help. Setting to NW for the issue summary update.

Localize.drupal.org does not show any untranslated strings in 9.3.0 for German: https://localize.drupal.org/translate/languages/de/translate?project=dru... so there must be some string discovery issues in potx module or some dynamic translation problems in core or both. Some examples or even better a full list of these strings would be great to see.

I agree with @quietone it would be beneficial to split the issue into either two child issues and perhaps rephrase the IS of the parent here or create two separate issues.

#1: I've tested with 9.3.0 as well as 9.4.x-dev. Both behave identical and I would say the issue is not fixed. I've tested on MacOS 10.13.6 with Safari 13 as well as the latest Firefox, Edge and Chrome. In Safari, Edge and Chrome the browsers auto detection was able to detect the system language and to auto select german. In Firefox that auto detection failed and it stuck to English.
I agree with @joachim-namyslo in general about the translation of the installers start page but would suggest a slightly different take. The strings choose language, Translations will be downloaded from the Drupal Translation website. If you do not want this, select English. and the button save and continue should be definitely displayed in the language selected (for reference the current state https://www.drupal.org/files/issues/2019-04-24/installation-process.png - applies to 9.4.x-dev still). But I would hide/remove the steps in the sidebar for the select language page of the installer. that would reduce the number of strings from 9 to 3 necessary for the first page. But there are several more strings in the installer workflow afterwards that are not shown translated.

step (website install): Initializing., Installed %module module. and Completed @current of @total.
step (configure translation): Initializing.
step (configure website): the selectbox about the timezones is not translated (but hard to spot since only the groups like europe are displayed - correctly translated into german it would be called europa instead)

But the odd part if you search for the aforementioned strings in either /web/sites/default/files/translations/drupal-9.3.0.de.po (for 9.3.0) or /web/sites/default/files/translations/drupal-9.x.de.po (for 9.4.x-dev) the strings can be found in the po file. So they are there and available but just not displayed? The exception are the three strings from the initial choose language page (but that is a different case imho).

#2: I've noticed that particular issue on the Add new language page (admin/config/regional/language - in case the language selected in the admin menu is != english). And after some digging i've discovered the issue here. So the biggest chunks leading to the 15 pages of untranslated strings are the already mentioned timezones. but the other important chunk are language names. they are not available as well. As already mentioned if you search for those strings on localize.drupal.org they aren't there. I've also downloaded the strings of the 9.3.0 release to a po file. they aren't there either. Country names are there yes but no time zones nor language names.
If you take a look at a local installation they aren't there either: /web/sites/default/files/translations/drupal-9.3.0.de.po is more or less the same po file like the directly downloaded one from localize.drupal.org. But if you go in your local installation to admin/config/regional/translate and filter only strings not translated yet you get a list mostly consisting of timezones and a few more other strings. Tried that with 9.3.0 as well as todays 9.4.x-dev. More or less identical only difference is the order.
BUT tried the display and export with a 9.4-dev sandbox from a few days ago (the project was not updated to the latest state/version yet). It contained the language names as well. For reference I'll add the po list of untranslated strings of the 9.4.x-dev install from a few days ago (withlanguagenames.po) and the po file for todays 9.4.x-dev install missing those language name strings (withoutlanguagenames.po). Hope that helps narrowing down the cause of the problem.

@Gábor Hojtsy, thanks. I am starting to makes sense of how this works.
@rkoller, thanks for responding quickly.

To make resolve either of the two problem in this issue what needs to happen next is to split this into two issues. It is not fair to expect anyone to have to work with two problem in one issue. And If they both need a commit that will not work well with tracking the changes in git.

I am tagging this as novice for the splitting this into two issues.

1. Create a new issue, titled 'Installer does not detect browser language'
   1. Copy everything about problem #1 from this Issue Summary to the template in the new issue.
   2. Add a sentence as the top of the Issue Summary, 'This moving problem #1 from #3050502: Untranslated string in core but not on localize.drupal.org to a new issue so it can be worked on independently'.
   3. Add this issue as a related issue.
   4. Save and check the new issue
2. Edit the issue summary in this issue and remove problem #1
3. Change the title of this issue to 'Untranslated string in core but not on localize.drupal.org'
4. Add the new issue, created above, as a related issue to this issue

There will be more work to move credit and a summary of the comments. But let's get the two problems into two separate issues first.

referring to #11
i would suggest to also add https://www.drupal.org/project/drupal/issues/3085219 to the list of related issues in step 1.3 . It is the issue about redesigning the installer for Claro.

referring to problem #2 (Check user interface translation against a minimal profile to find even more bugs)
I've investigated a bit more. The two biggest chunks of untranslated strings on localize.drupal.org are language names and time zones and both are not wrapped in t() function. Therefor localize.drupal.org (and the potx module respectively) is unable to add it to the created pot files from my understanding (am not a developer) and therefor also not available as untranslated strings on localize.drupal.org.

language names: They are defined in core/lib/Drupal/Core/Language/LanguageManager.php from line 233 on. That is the list of languages used in the installer but also in every select list displaying language names in the admin ui I guess.
The two options imho are either to display the name of each language in its native tongue like in the installer or make the language names translatable so users get every language list in the admin interface in the language set for the particular user account. From a usability perspective I would vote for the latter.

timezones: They are defined and downloaded in core/modules/system/system.module in line 1113. There just the timezone_identifiers_list() php function is called. The list of timezones that gets pulled is in english only apparently.
There might be an option half way by just translating the categories Africa, America, Antarctica, Arctic, Asia, Atlantic, Australia, Europe, Indian and Pacific since only the town names are shown in each category and not the whole complete string like europe/berlin. But nevertheless if you take for example europe/viennanot only the continent prefix differs and has to be translated but also the town name: europa/wien. So probably the cleaner and more accessible approach would be to make also all the available timezone strings translatable?

Problem could be related to #3126929: Translations are skipped when importing. There are ~50 untranslated strings in newly installed Drupal core because of that bug.

I've added the steps @quietone outlined in #11 in the Next steps section at the end of the issue summary for easier discovery and to provide clarity about the next steps for beginners as recommended by @volkswagenchick. I've then also added Prague2022 to the issue tags.

This issue is tagged for first time contributors at DrupalCon Prague 2022.

I think this is no longer a novice issue