Conversation
| const normalise = s => s | ||
| .replaceAll('_', ' ') | ||
| .replace(/([a-z])([A-Z])/g, '$1 $2'); // "camelCase" to "camel Case" | ||
| const normalise = s => s.startsWith('{') ? s |
There was a problem hiding this comment.
This protects only labels that begin with the placeholder (labels such as "Prefix {i18n>Foo}" would still be split) but should be fine in practice.
There was a problem hiding this comment.
Fair observation. Are you aware of a deterministic way to check for i18n labels we may be using elsewhere? Something like matching on /\{i18n>.*\}/?
There was a problem hiding this comment.
Yes, we should probably use the pattern /{i18n>([^}]+)}/g from cds.localize that's called downstream.
There was a problem hiding this comment.
Yours would probably work if you make it non-greedy (.*?) (and the backslashes are not required since {…} cannot be a repetition here) – but I'd stay with the reference here.
There was a problem hiding this comment.
Can do. I am actually not entirely sure what the desired behaviour for, say, MyService{i18n>foo} would be. Should we still give MyService the camel case treatment, or skip this altogether?
tim-sh
left a comment
tim-sh
left a comment
There was a problem hiding this comment.
Looks good to me, just flagging one observation.
This branch has not been deployed
2 participants
Fixes #180
i18n Tags like
TaskPluralare no longer normalised intoTask Plural, which broke the localisation itself.Note that the output of the openapi conversion is still locale neutrale. I.e. not setting a locale will still output the full i18n tag. Only when
--lang xxis passed are they replaced by the appropriate localisation value.