Yes, you’re right. And there are a bunch more with the same issue. I fixed most of them in PR 3817, but there are still some unresolved ones:
js.filters.latest.title
js.filters.unread.title
js.filters.new.title
js.filters.category.title
I didn’t fix them because those keys are heavily used in JavaScript and Ruby and I was under the false impression that pluralization doesn’t make sense in those cases anyway. @eviltrout Your weren’t happy about my last changes to the templates. How would you like to fix the pluralizations in this case?
I didn’t fix the remaining four translation keys since they probably need some changes to templates as well and you expressed your concern about those changes in your comment:
The client templates seem to be quite a bit longer with this patch and I thought zero was a nice feature.
Finding all occurrences of those js.filters keys seemed like a lot of work and I wasn’t sure if you even wanted me to change the templates the way I did.
What I need from you in order to finish my PR:
A decision regarding my template changes. Are they fine or should I solve this e.g. by using some kind of additional parameter with the i18n method?
Maybe some hints where the js.filters keys are used. Looks like the keys are concatenated most of the time which makes them hard to find.
Thanks for patience with me on this one! It has lasted so much time I’d forgotten some details.
Having reviewed everything I think your template approach is best. Sorry for the runaround but I think it makes the most sense even if it adds a bunch of logic.
That filter text is built programatically which is unfortunate. I think the following git grep shows most of the locations: