-
-
Notifications
You must be signed in to change notification settings - Fork 9.6k
[RFC] Deprecate bundle translations in Resources/translations #49634
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Hi! I think deprecating the old structure will only create a burden for bundle maintainers and not really have any benefit. Any bundle that supported Symfony <4.4 uses the old structure and must be updated to the new structure in order to be compatible with Symfony 7.0. While the migration for a single bundle might not be costly, having to do it for 10,000+ bundles will make it costly. I think it's better to let bundles update whenever they feel like it (if they ever feel like it). Some bundles might be open to receive such contributions (but it's always good to first talk with the maintainer, e.g. in an issue, before making such changes). Then maybe, if the community has made the big part of the shift, we can think about deprecating this for Symfony 8 or 9. |
Thank you for this suggestion. |
The maintenance cost in Symfony is almost zero to keep support for the old path, while the migration cost for the whole ecosystem is far from being 0 (we also never forced bundles to migrate to the new structure for the locations of their templates for instance). So this definitely gets a -1 from me. |
Let's close as indicated by the previous comments. We can always revisit if the bundle landscape changes in 2 or 4 years |
Could it be planned on the long term, like the new type declarations that are introduced through 3 major releases? See: |
Note that the bundles in the Symfony mono-repo don't follow this package structure at all (because it would force them to stop following PSR-0/PSR-4 in the mono-repo itself) and there might be other projects with the same kind of structure. As the code needed to support the old location is literally 4 lines of code (2 of them being in the debug command), I don't think we will ever reach a point where the benefits outweight the cost on the ecosystem. Type declarations provide a big benefit once they are in place, so it made sense for us to work on that even if it involved a plan over 5 years. but in this case, I only see drawbacks. |
Description
Since symfony 4.4 6996e1c, folder
<bundle>/translations
folder is supported and a best practice.However
<bundle>/Resources/translations
it still supported but not recommended/mentionned in new versions.What do you think about deprecate usage of
<bundle>/Resources/translations
?Migration is not costly and bring harmonization for newcomers
Example
No response
The text was updated successfully, but these errors were encountered: