Localized plugin and CakePHP3.x

Question

Localized plugin and CakePHP3.x

dereuromark opened this issue 10 years ago · 29 comments

So @markstory and I discussed the future of this plugin regarding the next major version of the framework.

So basically:

Remove the hardcoded localized validation from the core.
Provide app/plugin hooks to allow this plugin to take over.

Validation::phone($number, 'Localized.De')

We have 3 methods defined by the interface:

phone()
postal()
personId()

That need to work this way, for sure.

Any comments regarding this approach?

Answer 1 · 2014-07-31T02:30:42.000Z

What about follow the same standard used on the core classes? Probably something like Validation::config(DeValidation::consume())

Answer 2 · 2014-07-31T11:36:13.000Z

@jrbasso Where would a developer do that? Would you be able to wire up multiple locales?

Answer 3 · 2014-07-31T13:10:58.000Z

Personally I think we should just use the providers system in 3.0 validators instead of the static class.

Answer 4 · 2014-07-31T13:49:45.000Z

Is something common to switch between locales? I know for big countries like US and BR they usually specify one language/locale and that's it, but I can see it maybe being an issue for EU.

One option would be call the Validation::config() every time you switch the context, or make the config receive multiple locale configs and simplify the usage, something like:

Validation::config('de', DeValidation::consume());
Validation::config('us', UsValidation::consume());
// Or shortly Validation::config(['de' => DeValidation::consume(), 'us' => UsValidation::consume()])

// Using it
Validation::phone($number, 'de');

Answer 5 · 2014-11-24T19:35:59.000Z

@lorenzo Are we more clear now how we can best hook this plugin into 3.x? To have an easy to use API for validation here?

Answer 6 · 2014-11-24T19:40:08.000Z

@dereuromark not yet, I will have a proposal once the validation stuff is re-worked

Answer 7 · 2015-04-04T14:13:33.000Z

@lorenzo Any news on this?

I think we should probably try to integrate/leverage existing and quite extensive validation libraries in 3.x.:

address: https://github.com/commerceguys/addressing
phone: https://github.com/giggsey/libphonenumber-for-php

Answer 8 · 2015-04-04T22:08:19.000Z

@dereuromark Integrating those variables is probably a good idea. The tools to migrate this plugin are already there. We just need to create Validation providers with country-specific rules. I don't have the time to do it myself, though... Would you like to lead the task?

Answer 9 · 2016-01-16T21:52:11.000Z

I started the new master branch for 3.x.
The question would now be how to best implement those libraries.

Answer 10 · 2016-01-17T13:14:27.000Z

@dereuromark Could the developer provide the format they wanted? Sniffing from locales seems a little too magical.

Answer 11 · 2016-01-17T13:26:42.000Z

I think so, providing some inversion of control we should be able to allow them to configure it way more freely than in the past.

Answer 12 · 2016-01-18T07:10:17.000Z

Hey ,

How about not require on cake , but only on the necessary package in the require ? It looks it needs validation and only intl . Or am I wrong in understanding it ?

Thank you

Answer 13 · 2016-01-18T07:49:40.000Z

@harikt That's true for now but this plugin also aims to provide translations for the core messages

Answer 14 · 2016-01-18T08:01:47.000Z

Are we fine with making a first 3.0.0 plugin release now?
We can enhance it with the mentioned vendor packages mentioned here on top in a future version maybe?

//cc @antograssiot

Answer 15 · 2016-01-18T08:10:46.000Z

@dereuromark ok for me

Answer 16 · 2016-01-18T09:33:15.000Z

@dereuromark I would like to update the global namespace to Cake\Localized before.
Any thoughts ?
i can handle it tonight or tomorrow

Answer 17 · 2016-01-18T09:45:33.000Z

Do we do that for any other core plugin? If not, I would not do it here either.

Answer 18 · 2016-01-18T09:52:14.000Z

@dereuromark I thought we does but it seems that only Chronos has it.

Answer 19 · 2016-01-18T09:53:14.000Z

Not everywhere. For instance, ElasticSearch has it ; Migrations does not have it.

Answer 20 · 2016-01-18T09:54:18.000Z

@MihaiTL ping for romanian language.

Maybe you can help us to determine wether this rom file or this ron file is correct.
If we keep both, is there a language code like ro_ron or ro_rom ?

Answer 21 · 2016-02-01T21:42:35.000Z

Hi,

both are ok. There should be made a consolidation from both. The name should be something like ro_ro not ro_rom, not ro_ron.

Regards,

Answer 22 · 2016-02-04T07:56:59.000Z

@MihaiTL thanks for your answer ! we'll keep the https://github.com/cakephp/localized/blob/master/src/Locale/ro_ron/cake.po file because it contains accents. I'll open a PR

Answer 23 · 2016-02-04T08:13:12.000Z

I'm 👍 for changing the global namespace to Cake\Localized.
Maybe we could prefix all CakePHP core plugins with Cake\ to avoid interferences with users plugins

Answer 24 · 2016-02-04T19:33:11.000Z

doh! I forgot about this. @dereuromark @HavokInspiration what's your opinion on the namespace update to Cake\Localized before we ship it ?

Answer 25 · 2016-02-04T20:32:40.000Z

That makes sense to me to prefix the plugins.

But we should probably do it for every plugins. I'm just afraid for the migrations plugin since migrations classes are subclasses from the plugin. But that concern can be discussed in the migrations repo.

Answer 26 · 2016-02-29T16:34:55.000Z

Sounds like we can release now!

Answer 27 · 2016-02-29T17:33:46.000Z

yeah go ahead @dereuromark if you find time for it.

Answer 28 · 2016-04-08T11:05:48.000Z

Hey guys, sorry to ask this here but I prefer it than creating a new issue for just a question related to localization.

In the readme file you say that I should copy the cake.po file to its location, but I also have the main cake.po file there (the one extracted using i18n extract).

Should I merge them? How? Manually?

Answer 29 · 2016-04-08T11:22:32.000Z

Ok thanks to lorenzo I've seen that it is a replacement, so I only need to replace it.