The locales_source table contains a lot of items with a preceding whitespace, and for some strings this may be right - but we are having severe trouble with this preceding whitespace while importing _localized taxonomy terms_ throught he translate interface. We can't see any reason why our taxonomy terms should have a preceding whitespace in the locales_source table (or why any other string that not has a preceding space in the t(' text here') function has it). It seems like some sort of bug.

What happens is the following;
- We import a .po file using the translate interface (any of the two methods) - the .po file is properly structured.
- Terms are successfully imported, but when we start using the site - new terms start showing up.
- The "orgininal" record, containing the proper translations for all languages, in the locales_source table now contains a preceding whitespace in the location field, and the new entries are empty.

We have managed to work around the issue by editing the .po file, and removing the whitespace - but this is a breach of the .po file format, so it can't be the proper way of doing this. Example:

#: term:609:name
msgid "Mainstream"
msgstr "Commercial"

Changed to:

#:term:609:name
msgid "Mainstream"
msgstr "Commercial"

Doing this makes everything work like expected.

Another thing I am wondering about is the version field in the locales_source table. I have versions 6.01, 1 and none - isn't the usage of this field standardized in some way?

There's a similar issue posted in the i18n queue #384794: Preceding white space inserted in locales_source

Comments

2xe’s picture

2xe commented

I checked with some other multilingual sites - they also have a pretty large number of items (in the thousands) with preceding whitespace.

gábor hojtsy’s picture

gábor hojtsy
he/him
Primary language Hungarian
Location Hungary
commented
Status: Active » Closed (duplicate)

This was indeed solved with #384794: Preceding white space inserted in locales_source.