Move readme.html and wp-config-sample.php translations to GlotPress

[SergeyBiryukov]

Plugin readmes are now translated in GlotPress, but if you want to translate (or maintain previously translated) readme.html and wp-config-sample.php files from WordPress core, they are ​still managed via SVN.

If we find a way to import these remaining pieces into GlotPress and export them when building a release package, translators would no longer need to deal with SVN at all.

[Otto42]

Question: Where do the translated versions of these two files end up being used? In ZIP files? If so, then this may need to be a core ticket since it would affect the build process for those files.

[SergeyBiryukov]

Replying to Otto42:

Question: Where do the translated versions of these two files end up being used? In ZIP files?

Yes, in localized packages like ​https://ru.wordpress.org/wordpress-4.8-ru_RU.zip. They are built on WordPress.org, so I think this enhancement belongs on Meta Trac, as it doesn't require any changes to WordPress core, unless I'm missing something.

[ocean90]

#4060 was marked as a duplicate.

[casiepa]

@ocean90 If I propose this, would it be feasible?

1. I create pot files for the readme and wp-config-sample
2. they get imported in translate.wordpress.org and become visible as subprojects of wp/dev (​https://translate.wordpress.org/locale/fr/default/wp/dev/)
3. The 100% translation needed for the package would remain for the current 4 subprojects, but if any of the new 2 subprojects reaches also 100%, the en_us version of readme and/or wp-config-sample gets replaced in the generated release package
4. Polyglot mentors make sure that the en_us pot files get updated on new releases (is there a place where we can store them so they can be picked up easily in case of changes?)

Sorry for that ping, this won't work, need to think of another way.

/cc @nao @tobifjellner

[casiepa]

How about this as a start? Changes to the file could be maintained by Polyglots as part of release process, strings could go into Translate and files could be generated and added into the locale packages.

[Nao]

For reference of impact: At 5.7 release, ​at least 12 locales missed in-time package creation because of the missing svn directory.

And several others also spent time creating the directory (mostly) just to get those two files translated.

[tobifjellner]

I'd suggest an alternative approach for readme.html:
The file doesn't need to be included in the installation package zip. Instead, we could just publish it on the corresponding Rosetta site so that anyone interested could view or download it from there.
wp-config-sample.php is a bit trickier, since it would need to be there during the installation in order to get a nicely localized wp-config. But we could develop a wp-config how-to document, that describes and explains the various corners of the English wp-config instead. If we want to elaborate more, then we could allow the site visitor to select for which WP version they want to see/download these documents.

And then we publish this one, too, on Rosetta. And wipe out i18n.svn and have a party!

[dd32]

Replying to tobifjellner:

I'd suggest an alternative approach for readme.html:
The file doesn't need to be included in the installation package zip.

Unfortunately, the readme.html file must exist within WordPress release packages - as the core upgrade routines expect it to exist. Removing that check would then just result in having older installs being unable to upgrade to a more recent version.

However, the files contents does not matter, it could just be "See this page for documentation".. or english with a locale selector that loads the W.org page..

[tobifjellner]

@dd32 The en_US readme should stay in the installation package. I'm just saying that we would not put the localized version there.

[xavivars]

The Catalan team missed both 6.0 and 6.1 because we didn't have these two files ready on time, even if localizations were at 100%. But we still think they are valuable for the Catalan-speaking community to have.

If anyone can think of a way to manage localizations of these files in GlotPress, it would be great...

[dd32]

I'm bumping the priority of this, it's super less than ideal that we don't build localised packages for some locales at release time.

Example of where this came up ​#core61668