Skip to content

[Translation] MessageCatalogue::add() accepts non-string messages #49894

Closed
@rob006

Description

@rob006

Symfony version(s) affected

5.4.22

Description

MessageCatalogue::set() expects message to be string, but MessageCatalogue::add() (and the same applies for constructor) does not have any validation for messages array and in practice message could be anything, for example null. This creates inconsistencies, because MessageCatalogue::all() may return these keys with null as value even if MessageCatalogue::has() will return false for them.

In my case loading https://github.com/rob006-software/flarum-ext-last-post-avatar/blob/1ab3d5a5a7b8959f77481e389a1aba08bf97d37f/locale/en.yml resulted rob006-last-post-avatar.forum key with null as value, which resulted deprecation warning in Flarum, because they do not expected that MessageCatalogue::all() may return non-string messages (see rob006-software/flarum-ext-last-post-avatar#2).

How to reproduce

$catalogue = new MessageCatalogue('en');
$catalogue->add(['test' => null]);
assert($catalogue->all() === [] || $catalogue->all(['test' => ''])); 

Possible Solution

I think that all messages should be cast to string before adding to MessageCatalogue::$messages. I case of loading YAML like https://github.com/rob006-software/flarum-ext-last-post-avatar/blob/1ab3d5a5a7b8959f77481e389a1aba08bf97d37f/locale/en.yml I would expect that these null-keys will be completely skipped, but I'm not sure if skipping them in MessageCatalogue::add() would be a good place to do this.

Additional Context

No response

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions