Thanks to visit codestin.com
Credit goes to github.com

Skip to content

[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

Closed
alamirault opened this issue Mar 7, 2023 · 6 comments
Closed

[RFC] Deprecate bundle translations in Resources/translations #49634

alamirault opened this issue Mar 7, 2023 · 6 comments
Labels
RFC RFC = Request For Comments (proposals about features that you want to be discussed)

Comments

@alamirault
Copy link
Contributor

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

@carsonbot carsonbot added the RFC RFC = Request For Comments (proposals about features that you want to be discussed) label Mar 7, 2023
@wouterj
Copy link
Member

wouterj commented Mar 7, 2023

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.
Also, all bundles maintained by the Symfony organization are still using the old structure so it'll be quite costly for us as well 😅

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.

@carsonbot
Copy link

Thank you for this suggestion.
There has not been a lot of activity here for a while. Would you still like to see this feature?

@stof
Copy link
Member

stof commented Sep 8, 2023

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.

@carsonbot carsonbot removed the Stalled label Sep 8, 2023
@wouterj
Copy link
Member

wouterj commented Sep 8, 2023

Let's close as indicated by the previous comments. We can always revisit if the bundle landscape changes in 2 or 4 years

@wouterj wouterj closed this as not planned Won't fix, can't repro, duplicate, stale Sep 8, 2023
@alexislefebvre
Copy link
Contributor

Could it be planned on the long term, like the new type declarations that are introduced through 3 major releases?

See:

@stof
Copy link
Member

stof commented Sep 15, 2023

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
RFC RFC = Request For Comments (proposals about features that you want to be discussed)
Projects
None yet
Development

No branches or pull requests

5 participants