Fix translation extraction

[jotoeri]

Two small things:

• As plural-translations have a format of n('%n Action', '%n Actions', n) the extraction needs to use parameters 0 and 1. Didn't get recognized, as there are currently no plural-translations on this repo.
• Currently, translations do not get extracted if they are directly written within a html-property. Normally that should be fixed on extraction, however, the author seems to be on a bigger rewrite (since two years? Can't extract from angular template component input attributes lukasgeiter/gettext-extractor#31 🤔), so this is a quick and simple workaround to put them on new lines.

[skjnldsv]

Seems weird, and most likely invalid with our styleguide 🤔

[jotoeri]

Yeah, however linter does not complain, i checked that as i was also expecting some problems... 🤔

Alternative approach would be this, it's just a bit more of code...

data {
  return {
    closeTranslation: t('Close')
  }
}

[skjnldsv]

Why do you need the newline anyway?

[jotoeri]

npm run l10n:extract respectively gettext-extractor (build/extract-l10n.js) did not recognise it within an html-tag. So no extraction, no translations on transifex... 😢

Here e.g. the close-button is not translated:

[skjnldsv]

Can't we fix the gettext-extractor directly? No one is going to remember putting new lines :/

[jotoeri]

I didn't find a way... A PR on the repo seems not worth the work, as there are other PRs that just didn't get merged (see linked issue above and this PR).
Only other way, that i could imagine would be to use a html-parser with specific html-tags t and n to put the translations in a second time, but thats even more hacky.
Or just some completely different parser-package... 🤔

[jotoeri]

Any preferences? As i said - i don't see us currently fixing the extractor.

• Using the given way or the proposed data/prop way? The latter is probably a bit cleaner, but 5 LoC more. The prop could also be done as object l10n.close = t('Close')
• Just came to my mind that i could additionally add a workflow spitting a warning if some pattern ="t( is found. This is how i found those three occurences.

[skjnldsv]

data {
return {
closeTranslation: t('Close')
}
}

Let's use this syntax instead then, will be cleaner and easier to manage

The other option I could think of would be to build the dev webpack and parse the results

[jotoeri]

Ok, so it's this version now.

The webpack-dev-build i looked into for moment, but it seems to be not fully straight forward.