search

potsky / laravel-localization-helpers

🎌 Artisan commands to generate and update lang files automatically
GNU General Public License v3.0
187 stars 39 forks source link

Dont expand #52

Closed schniper closed 2 years ago

schniper commented 7 years ago

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 commented 7 years ago

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 :

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 :

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

It will work for :

What do you think about this ?

schniper commented 7 years ago

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 "family.key1.key2.@.phrase 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 commented 7 years ago

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

schniper commented 7 years ago

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

potsky commented 7 years ago

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 commented 7 years ago

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 notifications@github.com, 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 commented 7 years ago

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

schniper commented 7 years ago

Ok! :)