Merge lp://staging/~unity-team/music-app/infographics-translations into lp://staging/music-app/remix

1 inline comment: Is there a reason for changing the format here?

If someone else can get around to testing this, that'd be great. Otherwise, I can do so tonight.

Also note, we had a similar MP that was rejected by David Planella [1] for changing the format as a workaround to the singular/plural issue. I don't know if that's your intent with the format change here or not... I believe the preference would be to still use the current translation/format. Additionally, changing the format would require the string be retranslated in each language.

1 - https://code.launchpad.net/~andrew-hayzen/music-app/fix-infographics-1351421/+merge/229506/comments/558727

The reason for changing the format string is because it's not possible to do natural translations with correct plurals, as the infographics work with floating point numbers, and gettext only supports integers.

I have done my best attempt at updating the translations here. If you want to keep the format string the same, one of the music app developers will have to make a change that is acceptable - this is just me trying to help out.

Thinking about it more, I don't think we have a choice about changing the format string.

The app is doing translate(prefix + "translatable_string") -> infographics server.

The "translatable_string" gets extracted into the catalogue.

The infographics server then tries to translate translate("prefix+translatable_string"). This won't work for two reasons:
1) The catalogue contains "translatable_string" instead of "prefix+translatable_string"
2) The combined string has already been translated by the music app.

We need to simplify all that and just put a straightforward translatable format string into the catalogue, as I have done in this MR.

I've added dpm to this review. It sounds like the following would still be acceptable to your solution:

format: translateMe("<b>%1</b> songs played today")

Clearly that would still require the translations to be updated, but it'd also avoid the natural language for plurals issue. But if the direction for all apps using the infographics will be to use the same workaround, then the Music app should follow.

Well it won't truly avoid the plural problem, due to the issue of the different plural forms for different languages.

However I don't feel strongly about exactly what string will be used in the music app, so if you definitely want to use the one you suggest, that's fine by me.

After discussing it on IRC, we've agreed that rather than introducing a new custom translation function, it would make more sense to extend the i18n.tr() API.

See bug 1417031

We still need to broadly make this change, even if we use the proposed i18n.noop() function. I will update the MR accordingly.

This now looks more inline with the SDK, good work!

Just two comments:
- See inline comment for RTL languages
- I know it's a separate issue that we'll handle separately, but just for the record we should see if we can find a solution or a workaround for supporting plural forms. From my understanding from talking on IRC, the limitation lies in the fact that in theory libusermetrics could be showing floating-point strings, but gettext supports only integers for plural forms.

Approve, but pending the i18n.noop() merge from the SDK upstream

I believe I have updated the RTL languages now (I used the list of RTL languages on Wikipedia as a reference).