Dont expand

[schniper]

Allow translations in the form __('labels.phrase.Loading records...') to yield a translation of 'Loading records...', by marking 'phrase' as a non-expandable key. Otherwise, we would end up with an empty translation (the last element of the exploded key). This, of course, works only in conjunction with the -w flag.

@potsky sorry, I know it's a branch on master. If the idea is ok, tell me where to relocate it and I'll do it. Haven't contributed to anything in a while...

[potsky]

Hi @schniper,

master branch is ok. But are really sure you want to use your feature ? It means you need to edit 2 files each time you have dots in a sentence : the lang file and the configuration file. It is a little bit annoying, isn't ?

You have a very good idea and I think we can really improve it.

Perhaps we can check for tokens from the $dont_expand_keys array instead of exact matching strings.

By default, we could put the string ..., . (dot then space) and ??? in your array and it would work for :

• Loading records...
• This is a sentence. The second sentence is detected because the space next to the dot is included in the array
• WTF ???
• ...

Then, why use this feature only with the -w flag ? It could be used in all cases. We can remove the match strings from the detected lemma and build the lang array without these matches.

Example :

• message.alerts.Loading records... Please wait... becomes ↩
• message.alerts.Loading records Please wait then key is built without dots in the message family file in the subarray alerts↩
• Loading records Please wait => TODO: Loading records... Please wait...

Then instead of just settings strings in the $dont_expand_keys array, we could add regex too ! For example :

• @\.$@
• @\.\.\.$@

It will work for :

• Loading records...
• This is a sentence.

What do you think about this ?

[schniper]

Regexes would surely make it a lot more flexible, but there will be cases difficult to handle (what if I have a phrase that simply contains a period, no extra spaces? How to distinguish that from the regular key separators?)

Instead, I was thinking that the trigger could be shorter, like maybe "[email protected] containing dots" and this could be something built into the library. Just document that if you precede a phrase by .@., what follows will not be interpreted anymore. What do you think? This gets rid of all the extra configuration, while making translation of longer phrases totally doable. No matter what they contain. Indeed, to make it work without -w, your idea of stripping the periods from the key section is perfect. The @ (or something similar) would also work as a visual queue, showing the developer that what follows represents a whole translation string. Like an escape sequence.

What say you, @potsky ? :)

[potsky]

Regexes would surely make it a lot more flexible, but there will be cases difficult to handle (what if I have a phrase that simply contains a period, no extra spaces? How to distinguish that from the regular key separators?)

It is mathematically impossible to understand the meaning of a dot in fact.

Your idea of adding a dot escape char is obvious! Congrat's! It is simple and efficient. We can just add an array of allowed escape chars in configuration and it is perfect.

Here are some examples with the @ escape char:

message.alerts.Loading records@.@.@. Please wait@.@.@. will produce

• key : Loading records Please wait in family file message or simply the original one Loading records@.@.@. Please wait@.@.@. which is better I think
• value : TODO: Loading records... Please wait...

[schniper]

Thanks :) That would work as well, but I was suggesting to put a single escape sequence, after which every dot is ignored. Example: [email protected] records... This looks much cleaner then escaping each dot individually.

[potsky]

Thanks :) That would work as well, but I was suggesting to put a single escape sequence, after which every dot is ignored.

This is not a good idea :-( It is not reliable. But I will add the escape char feature and the regex feature too :-) So your idea will work with a regex ! I will try to release a new version before the end of the week.

[schniper]

Great!

-- Costin Bereveanu

Unless otherwise stated, this e-mail message, its attachments and all future replies and attachments related to it are to be considered confidential and exclusive property of their senders/authors. Copying and/or distributing any of them in their entirety or in part for a purpose outside their scope (as considered/defined by the sender) is forbidden in the absence of a prior consent from the sender. If you have received this message by mistake, please be so kind to delete it and notify the sender.

On 28 Feb 2017, 19:18 +0200, Potsky [email protected], wrote:

Thanks :) That would work as well, but I was suggesting to put a single escape sequence, after which every dot is ignored. This is not a good idea :-( It is not reliable. But I will add the escape char feature and the regex feature too :-) So your idea will work with a regex ! I will try to release a new version before the end of the week. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[potsky]

I will implement this feature in the v3. I need to rewrite the extension to do this

[schniper]

Ok! :)