<!-- Note to translators: the following 18 entities are used to construct a - sentence (either the SP or DDG entities are used, but not both at the - same time). In English, the sentence reads: - Search securely with Startpage. - or: - Search securely with DuckDuckGo. - The sentence contains two embedded links for "securely" and - the search engine ("Startpage" or "DuckDuckGo"). -->
That's really, really not the way to do it. Isn't there an equivalent to sprintf for
Firefox extensions?
The following strings can't be translated properly with Transifex:
Assembling this string dynamically should be possible, but I think that means we will have to invalidate existing translations and convert these to properties instead of DTD elements. It may also require Javascript running in about:tor to do this, though we may be able to assemble the strings in Torbutton and inject them.
If we end up needing to inject them anyway, I suppose an extreme hack might be to create a hidden XUL element with the DTDs in it, extract the elements they are contained in, and reassemble them in JS, and then inject that into about:tor. That will require us to invalidate less strings (perhaps only the ones with spaces), but it might be a little crazy and messy.
We did not realize/think about the fact that Transifex would make it impossible to see the spaces. We followed the kind of scheme Mozilla uses for similar text within the Firefox about box, e.g.,
The easiest fix is to move the spaces into aboutTor.xhtml and remove them from the localization process. It is possible for some locale that a space between the pieces would not be desirable, but I don't know of a real world example. The advantage of this solution is that we can probably keep all of the existing translated strings.
Another approach would be to use more of the sprintf approach as lunar suggested. We could have a property string something like this:
This would still give translators control over the order of items within the final string, etc. with the downside that the existing entities would need to be thrown out. Also, translators would have to preserve the HTML tags and balance quoting within the one string, which is very fragile.
We also noticed that in some of the translations have " " in aboutTor.dtd instead of " " or " ". This causes ;nbsp& to show up on the Arabic about:tor page.
This is one of the affected entities: aboutTor.searchSP.privacy.afterLink.label
The following localizations have the problem:
ar de es fa fr it ja nl pl pt ru zh-CN
We did our best to preserve the existing translated strings, converting
them to the new scheme and adding the missing spaces.
Mike -- you will also need to update the trans_tools/import-translations.sh script once the new aboutTor.properties file has been added to the translation repo.
Feel free to tag any tickets that are ready for review+merge with MikePerry2014MMR, so I can easily find them while merging things for a given release.