fix: harmonize quotes usage in messages

[rdeltour]

Use double quotes everywhere to fix #1071.

Note: the messages style is still not entirely uniform. For instance, sometimes element and attribute names are quoted, sometimes they aren't. I suggest this is dealt with later on in a different issue and PR. (A massive review of messages and rewording wouldn't hurt readability and understandability).

[rdeltour]

@tofi86 This PR massively updates the main message resource bundle, but only for quotes. What's the best way to propagate this to localizations? Should I replace the quotes in the localized bundles too?

[mattgarrish]

Probably for another update, but I would have expanded the contractions instead of using a stylized apostrophe. You never need a contraction, and using "doesn't" and "can't" reflects a very informal conversational style.

[tofi86]

@tofi86 This PR massively updates the main message resource bundle, but only for quotes. What's the best way to propagate this to localizations? Should I replace the quotes in the localized bundles too?

Phew... That's a good question...

From what I see at first glance, we can upload a translation bundle directly in Transifex for every language for every message bundle:

That said, I think the best solution at the moment is, to

1. locally pull ALL translations, even the mostly incomplete
2. manually replace all the quotes in all localized bundles per your suggestion
3. push the changes, at least for those languages with > 50% translated content
4. merge this PR to master
5. wait for one of the two daily auto-updates on the transifex project to run. This will update the english message bundles and cause all dependent messages in all languages to change to "message update to be translated".
6. quickly upload all altered message bundle updates manually in transifex (maybe the tx client also has an option for that to do programmatically?!)
7. quickly because then, translators will most likely not notice any changes after checking for the "message update" email

[tofi86]

From what I see at first glance, we can upload a translation bundle directly in Transifex for every language for every message bundle:

• https://docs.transifex.com/translation/importing-translations

6. maybe the `tx` client also has an option for that to do programmatically?!

We seem to be lucky:

• https://docs.transifex.com/client/push

To push translation files, use the -t or --translations flag with the push command:

$ tx push -t

You can also combine the two flags to push source and translation files together:

$ tx push -s -t

[tofi86]

Sorry for the close and prematurely posting the comment.

We seem to be lucky:

This means, we can combine 5.+6. in a single automated tx push -s -t

[rdeltour]

Many thanks @tofi86 for looking into this and for the suggestions 👍. Makes sense to me, I'll try to update Transifex this way once the PR is updated and merged!

[rdeltour]

@tofi86 so, I pushed all fixed message bundles (source and translated) with tx push -s -t, but now most of them appear as "100%" translated in Transifex. Even if not all strings are translated (typically the new RSC-023).

I'm not sure what to do from here 🤔. I can probably broadcast a message to all translators to check their translation for English strings, unless you have a better idea 😊

[tofi86]

Can you try pushing only the source files again with to push -s? I think this should result in Transifex updating the source strings, making a diff and recognizing the new/empty values in the translations.

[tofi86]

Maybe we also need to wait for the transifex Auto Update? 🤔 I don’t know exactly...

[rdeltour]

Yeah, I did try tx push -s. I also tried removing RSC-023 from one of the translated bundles and use tx push -t. Neither of this seemed to work.
I could always go and remove this particular string manually in Transifex, but some languages have other non-translated-appearing-to-be-translated strings 😔

[tofi86]

even if not all strings are translated (typically the new RSC-023).

I think this is because you added the new english message also in the translation message bundles

e.g. https://github.com/w3c/epubcheck/pull/1132/files?file-filters%5B%5D=.properties#diff-54365c31b95e8f4c91cf8edd95868a24L326

If you replace them with an empty property and push translations again, I guess Transifex will recognise it correctly.

[tofi86]

but now most of them appear as "100%" translated in Transifex. Even if not all strings are translated

Unfortunately I didn't remember the state of all translations.

However, if THIS

https://github.com/w3c/epubcheck/pull/1132/files?file-filters%5B%5D=.properties#diff-119dbf5b36625f98e63a8431c1da8997L130

is not a new message but was copied over from english to nl by you, I guess it's the same mistake as I mentioned above for RSC-023.

It seems that the untranslated keys must be empty when pushing with tx push -t...

[rdeltour]

As I said above I did try to remove RSC-023 from one of the translated bundles and push with tx push -t, but it didn't seem to propagate to Transifex. 🤔

Maybe I didn't give it the time to update properly. I'll try again later. If it works, I'll try to manually spot all the English messages in translated bundles and remove them… 😅

[rdeltour]

By the way, for clarification I didn't add the english messages myself: they somehow got integrated when pulling from Transifex (with the build script).

[tofi86]

Sorry, it seems I missed that...

Oh damn, that's indeed a bummer... :-/

I could try to take a closer look this weekend, but I cannot promise getting to it...

[rdeltour]

Sorry, it seems I missed that...

No worries 😊

I could try to take a closer look this weekend, but I cannot promise getting to it...

Well, I'll try again tomorrow. Don't waste your time on this… practically it doesn't change anything for the end user, it just makes the Transifex UI a bit less informative. Translators will have to pay extra attention in their next translation round!