The audio event names have not been localized.

[ZhaiSoul]

When I was submitting the i18n PR, I seem to have missed something. Currently, on the explore page, some audio events are not being localized correctly. This is because the explore page only reads the language files for objects and does not utilize the language files for audio. Perhaps some improvements should be made here.

I'd like to ask everyone: do you think the language files for audio and objects should remain separate, or should they be merged together? I'm concerned that merging them might lead to some ambiguous naming issues.

[inkeep-ai-assistant[bot]]

---

Based on the available sources, there's an active discussion about i18n support in Frigate. The community is working on translations through Weblate for the 0.16 release(1).

Regarding backend localization and how audio/object labels should be structured, there's an open GitHub issue discussing i18n support for the backend(2). The maintainers have noted that backend localization requires careful planning, particularly for use cases like the config UI, notifications, and MQTT messages(2). One contributor suggested adding a middleware layer on the backend to handle localization properly(2).

For your specific question about whether audio and object language files should remain separate or be merged:

The documentation shows that audio events use labels like bark, fire_alarm, scream, speech, and yell(3)(4), while object detection uses labels like person, car, cat, etc. These are configured separately in the Frigate config(4)(5).

From the translation discussion, contributors have been working on separate translation files for different components, and there's mention of an objects.json translation file(1). The explore page issue you're describing (where audio events aren't being localized because it only reads object language files) suggests the current implementation may need refinement.

Given that:

1. Backend localization is still being planned(2)
2. The translation work is ongoing for 0.16(1)
3. Audio and objects serve different detection purposes(3)(4)

I'd recommend keeping them separate to avoid ambiguity, but ensuring the explore page (and other views) properly load both translation files when needed. This maintains clear separation of concerns while fixing the localization issue you've identified.

You might want to contribute your findings to the existing GitHub discussions(2)(1) to help guide the implementation.

📚 Sources:

1. Frigate 0.16: Request for Community Help with Translations (i18n)
2. Add i18n Support to Backend
3. Audio Detectors
4. Full Reference Config
5. [Support]: Events/Detections not happening for audio

---

Have another question? Just tag @inkeep.

[NickM-27]

I didn't see a reason to merge them. It's easy enough to work around this.

[ZhaiSoul]

Yes, I agree that keeping them separate is more appropriate. My current plan is to modify the i18n.ts file - if the namespace (ns) is 'objects' and no corresponding translation is found, it will then try to look up the audio namespace.

[NickM-27]

I don't think there's a need for that. We already know if an event is an object or audio

[ZhaiSoul]

I don't think there's a need for that. We already know if an event is an object or audio

That's even better. I'll review the relevant code.