Option for custom id transforms.

[sullivanpt]

A custom id mapping can be provided. Examples: // do not trim the whitespace from the string ends (the current default) 'idTransform': fn(s) { return s; } // apply html whitespace trimming rules 'idTransform': fn(s) { return s.replace(/\s+/g,' '); }

I am also submitting a matching pull request for rubenv/angular-gettext References rubenv/grunt-angular-gettext#1, rubenv/angular-gettext#183

[rubenv]

Don't think I will merge this.

If you change the keys during extraction, you'll have to do the same transformation at runtime, otherwise they won't match. Which adds another confusing configuration option.

No extra configuration in angular-gettext unless it's strictly needed.

The real question here is: why do you really need this? What problem are you currently facing?

On Wed, Apr 18, 2018, 15:41 Vytaliy Makovyak [email protected] wrote:

@startusin commented on this pull request.

👍 Is it possible to merge it? Please

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/rubenv/angular-gettext-tools/pull/90#pullrequestreview-113250010, or mute the thread https://github.com/notifications/unsubscribe-auth/AACnmB19fHHPxwoXHCHmNWXVxQRZNZdgks5tp1C0gaJpZM4EKG6T .

[sullivanpt]

Wow, this is so long ago I forgot I made this PR. In my case we have multi-line HTML content processed on Windows and Mac developer PCs, so the intermediate whitespace (between lines) can sometimes be line feed, and sometimes be line feed + carriage return, and this makes the exact string white-space matching fail on one host or the other depending on which host was used for the extraction step. In addition to that major annoyance, it's also a little bit confusing for the translators to see all the extra white space between words in the PO file; remember when the browser renders it removes all the extra whitespace. This option gives us the ability to make keys that are platform independent and that look more like the browser actually renders them.

The provided test case in this commit illustrates the problem pretty succinctly.

For the record, we've been avoiding the issue a different way in our code altogether by never having any HTML text with an embedded line break; yes, we have REALLY long lines :-).

Anyway, it would be great if you merge this, but it's not essential. And also, thanks for the amazing library. I've loved using it these past few years.