@carolromero you can check this out on https://osp-decidim.dev.aspgems.com/initiatives

@virgile-dev I'm not so sure about this one. I understand that there are different "levels" or categories of status:

• The top level: open or closed initiatives.
• A second level: If it has been accepted, rejected or is in validation, because you can have accepted initiatives, whether they are open or not, right?
• Finally, the fact that they have been answered or not belongs to a different "level" from the two previous ones.

So it seems to me that this change in the filters can be confusing. I don't have a clear solution, a priori I think it's better to leave only the upper level (as it is now), although maybe we can think of some alternative. Thoughts? cc @decidim/product

Hello @carolromero
Thanks for your feedback !

• Open = end date for signature collection period hasn't passed yet
• Closed = end date for signature collection period has passed (signature collection date cannot be changed once an initiative accepted or rejected)
• Only initiatives which end date for signature collection period has passed can be either accepted or rejected. So it makes sense it's a sub-filter of closed.
• Initiatives can receive answers at any time regardless of its signature collection period dates. That's I figured it could be first level too.

@virgile-dev sorry I'm late! Thank you for clarifying, sometimes I mess myself up with so many options 😬
I guess what I find a little confusing is the name of the Accepted and Rejected labels if it actually refers to the number of signatures collected, although that was before this PR. We have discussed it with product and we thought that this way it would be more understandable:

• Open
• Closed
  • Enough signatures
  • Not enough signatures
• Answered

@virgile-dev @ace what do you say? Do you think we can make that change? 🙏

@carolromero sure we can change the translations.

Just to be clear you want us to change accepted and rejected to the ones you suggest everywhere not juste in the filtering box right ?
This means on cards, on the page etc.

Just to be clear you want us to change accepted and rejected to the ones you suggest everywhere not juste in the filtering box right ?

@virgile-dev that's right, to be consistent, yes. thanks!

@ace could you apply the changes in locales that carol requested ? Thanks in advance !

Changed both texts in filters, lists and cards.

@carolromero @virgile-dev The changes are on https://osp-decidim.dev.aspgems.com if you want to check them.

Hi @ace, could you please check the remaining failing test?

Hi @jesusdb. I think I need some guidance here. I saw that test, but it shouldn't be failing. It's complaining about unused l18n keys that are if fact used.
Both the keys and the usage were added in the same commit, c833bfa (the badge_name ones).
You can see two of them in the last screenshot above, the '(not) enough signatures' labels in the initiatives card.
Any idea how that can be solved? Is there any way to make the test find those keys usages?

Any idea how that can be solved? Is there any way to make the test find those keys usages?

Let me chime in here, this is a problem that comes back from time to time. You can force the identification of i18n keys by creating a comment somewhere in the code.

For instance:

 # i18n-tasks-use t('decidim.admin.exports.formats.JSON')

There's also the possibility to edit the config/i18n-tasks.yml file, but I found the comment method a little bit more clear.

Thanks @microstudi, those comments fixed the missing keys issue. Now it's complaining about a non-normalized locale file in the proposals module, should that be fixed here?

Thanks @microstudi, those comments fixed the missing keys issue. Now it's complaining about a non-normalized locale file in the proposals module, should that be fixed here?

Just do what the test says and it will fix it:
bundle exec i18n-tasks normalize --locales en

Yeah, I did that but found out the offending file doesn't belong to this PR (not even the initiatives module, it's from proposals), that's why I'm not sure about fixing it here.

Maybe it is related with the fact that some keys used in initiatives where moved to proposals recently (because they were used un both). Can you check what is changed by the i18n task?

I'll recheck when I can get back to this branch, dealing with that nil in the other one :)
But it makes a lot of sense, normalize was removing two keys from the proposals for accepted and rejected states, I've changed that here to use explicit keys so maybe initiatives was using some kind of generic proposals keys.

Actually, I made the PR with the change, check this: #6013

@jesusdb could you check if can merge this now ? Thanks !

Could you check the changelog conflict, please?

We're currently looking on a way to automate and fix the changelog conflicts to avoid these situations

Done. That automation would be great, I can't remember how many times I've had this conflict in the last days :)

Yes, it's a pain... This will change at the next version. PR won't have to deal with changelog anymore

It seems coverage upload timed out, can you re-run?