-
Notifications
You must be signed in to change notification settings - Fork 321
dynamic languages #54
Comments
Why not use |
What I'm suggesting is having more flexibility. Both the current option + a dynamic option. Where you can even have 'active' languages, those that can be disabled in the backend of an application for instance. I would suggest normalising, as in using a 'language_id' in models to pinpoint to specific languages, this would also help in cascading deletion where if you delete a language, all models pertaining to said language would also be deleted. |
One reason I like this package is that it's small with one responsibility. Perhaps making another package that extends laravel-translatable should make sense ? What do you think ? |
Fair point, Then I would suggest events for this package for easy hooking...I would gladly create this package. |
I agree with @sdebacker, you can do whatever you want with Sorry but your use case is too specific to be included in this package. Feel free to create an extension or something. Cheers :) |
Is it really so specific though? Normalising the languages to a database? Ill be writing a package to extend this one but still |
By adding the languages to the database you add extra complexity which is rarely needed. Let's keep the package simple and open for extension. |
@wisepotato If you are still looking for a solution for your problem or someone in the future will look, you can see my fork: https://github.com/daverdalas/laravel-translatable |
So, love the package. But I have dynamic languages... Currently I am using a closure for the available languages in the config, but this is less than ideal.
Would this not be a nice addition to the package, to make a language table? It could also include a column for 'active', which could help in real-world applications.
Or atleast make it easier to use dynamic languages, couldnt think of a great way to implement this....
The text was updated successfully, but these errors were encountered: