Closed OwenMelbz closed 7 years ago
That would be nice, yes. But a big issue here is that we need to delete the old files in order to republish. And we don't know if the developer has made any modification to the language files - in which case we'd destroy his work.
I think a good alternative would be a combination of: 1) not publishing them by default. There has to be a way for us to use language files with fallbacks to the package files, but it didn't work for me. Needs more effort. 2) a db-backed langfile system, where all language strings are imported and where the developer or admin can translate the files; that way, he wouldn't need to modify the lang files at all and we can overwrite them; that's the LangFileManager rewrite I was talking about;
Ok, so I've spent too much time on this already. My conclusion is this: we can only fix the langfile loading problem in the next breaking change.
The fix is easy to implement, but difficult for updaters. Basically, the issue is that in every package, we're loading the langfiles with the same namespace (or hint), "backpack". So only the last installed package actually gets its langfiles loaded.
In order to fix this we need to:
1) In every package, change how translations are loaded in the service provider. For CRUD, for example:
- $this->loadTranslationsFrom(realpath(__DIR__.'/resources/lang'), 'backpack');
+ $this->loadTranslationsFrom(realpath(__DIR__.'/resources/lang'), 'crud');
- $this->publishes([__DIR__.'/resources/lang' => resource_path('lang/vendor/backpack')], 'lang');
+ $this->publishes([__DIR__.'/resources/lang' => resource_path('lang/vendor/backpack/crud')], 'lang');
2) In the views, change all language translation strings:
- {{ trans('backpack::crud.admin') }}
+ {{ trans('crud::crud.admin') }}
This will fix it for new users - translation strings will first be loaded from the published ones, then fall back to the ones in the package.
But we also need to instruct ALL existing users to: 3) Change the language translation strings in any views they've overwritten. 4) Move all their published translation files in the new directory structure.
...which... is a real pain in the ass for everyone.
I am not happy at all with this solution. My main two reasons are: A) I don't like it that you load translations strings by calling "crud" two times:
{{ trans('crud::crud.admin') }}
I don't like it at all. But I guess I can get over this.
B) It will be very very difficult for users to do this update to their views and translation directory structure, just because I messed up... So the only honest thing to do here would be to create a script to automate that for them. Four scripts, actually:
(each script in two flavours: unix and windows)
This does not sound like fun, but I'm afraid we need to fix this, because we'll be pushing new language lines in the package.
Does anybody have another solution? Please? Pretty please?
@tabacitu this needed for 3.2?
Yes, I think that's a good moment to do it too.
Added to consolidation list https://github.com/Laravel-Backpack/CRUD/issues/285
As more functionality gets added etc, more language files get updated, and you dont always ways to republish certain things.
It would be good to get something like
php artisan backpack::publish language
- which could be extended intophp artisan backpack::publish views
etc making it more simple for developers to update