So as the topic says, some strings that had been translated and accepted on localize.drupal.org were not included in the pre-exported file, the issue is regarding the Finnish translation for D8 alpha2.
What I did was the following:
- installed clean Drupal 8 alpha 2 and enabled Finnish language on it
- downloaded the pre-exported translations file for drupal 8.x-alpha2 (created at 2013-Jul-13) from localize.drupal.org
- imported the .po manually to the D8 installation
- checked the translation status on the installation and some strings were still missing a translation though most did get translated
After that I compared the .po file with what strings were missing a translation and realized that the source strings were missing in the .po file as well.
Examples:
https://localize.drupal.org/translate/languages/fi/translate?sid=1732993
The missing strings had been earlier translated and marked as accepted on localize.drupal.org so they should have been in the .po file.
Also realized that there are a lot strings which the "Translate interface" on my local D8 alpha2 installation finds as untranslated but they are missing on localize.drupal.org when filtering by Drupal core and release 8.0-alpha2. Now because the import is not working, I'm unable to add the missing translatable strings to localize.drupal.org, is there any other way to do this?
Not marking as critical but think this should be addressed as well, otherwise might lead to duplicate work for someone that is translating the D8 core.
Comments
Comment #1
aalamaki commentedComment #2
gábor hojtsyEven if you could import back .po files, the source strings will not appear on localize.drupal.org. You cannot add arbitrary source strings to projects that have not been identified as part of the project already by the server.
In terms of the actual string, https://localize.drupal.org/translate/languages/fi/translate?sid=1732993 is a string in JavaScript:
So this may be an issue with the new JS parser not finding these strings (given the extra newlines included). The older JS parser found these strings because it was not looking for context information. Any other strings missing?
Comment #3
gábor hojtsyI moved #1860254-30: Support for Drupal 8/7 context extraction for JS translations back to 6.x-3.x for fixing the JS parsing.
Comment #4
gábor hojtsyAny other strings missing? This would be really helpful to identify any other bugs in the new parsing code :)
Comment #5
aalamaki commentedHi,
Not sure...there were a lot that were missing completely in the .po file, I mean strings that the Drupal installation recognized as missing translation but were obviously missing on localize.drupal.org as they did not get translated when importing the pre-exported translation for D8 alpha2. On l.d.o, all the D8 alpha2 core translation strings that can be found there have been translated and marked as approved.
Comment #6
gábor hojtsyI'd love if you could provide data and I'd not dig into your website. Also if you can provide relevant data on this issue, that would let others coming later evaluate it regardless of whether your site is still up or not.
I think at least configuration contained translatables will not yet be covered on localize.drupal.org. There also may be bugs as shown with the JS translatables. We should see if there are anything else.
Comment #7
aalamaki commentedWell, ok there was a way to export just the untranslated strings; added them as an attachment. Looks like at least some of the strings originate from the *.yml files in the modules.
Comment #8
gábor hojtsyYou'll need to re-upload renamed to .txt since the Drupal built-in .htaccess disallows serving .po files.
Comment #9
aalamaki commentedAhh, ok done now...didn't realize that, it didn't complain about it when uploading.
Comment #10
gábor hojtsyMost strings in this list (if not all) are from default configuration. That is unfortunately not a trivial problem to solve. See #1933988: Support for Drupal 8 shipped configuration translatables with external dependencies (in effect contrib). Would be good to see if any of these strings is NOT coming from a .yml config file.
Comment #10.0
gábor hojtsyUpdating the post