You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Allow configuration of ensure_ascii in JSON logging for non-English characters #2280
Title:
Allow configuration of ensure_ascii in JSON logging for non-English characters
Description:
Currently, the JSON logging formatter in our codebase uses ensure_ascii=True by default. This causes non-English characters (such as Korean, Japanese, Chinese, etc.) to be escaped as Unicode sequences, which makes logs less readable and harder to debug for users working with these languages.
For example, a log message containing Korean text like "안녕하세요" is output as \uc548\ub155\ud558\uc138\uc694 instead of the actual characters.
Proposal:
We propose to modify the logging setup to make the ensure_ascii option configurable. Here are a few suggested approaches:
Configuration Parameter in WorkerOptions
Add log_ensure_ascii: bool to the WorkerOptions class
This would allow users to configure the behavior when initializing the worker
opts=WorkerOptions(
ws_url="ws://localhost:7880",
log_ensure_ascii=False# New parameter
)
CLI Option
Add a command-line flag to control this behavior
livekit-agent start --log-ensure-ascii=false
Plugin Configuration
Allow plugins to specify their preferred logging format
This would be particularly useful for plugins that need to handle non-English content
Questions:
Is there a specific reason why ensure_ascii is currently hardcoded to True?
If it's for compatibility or legacy reasons, could we consider making it configurable while keeping True as the default?
Would it be possible to update the logging formatter to support these configuration options?
Impact:
Making this change would significantly improve the usability of our logging system for international users and developers working with non-English languages. It would make debugging and log analysis much more straightforward for users working with non-English content.
Additional Context:
This is particularly important for applications that need to handle user input or generate content in non-English languages
Many logging tools and systems (like ELK Stack) can handle UTF-8 encoded JSON logs without issues
The change would be backward compatible if we keep True as the default value
Activity
longcw commentedon May 13, 2025
@theomonnom should we just remove the
ensure_ascii=Truein logs?zuber-ctrlagent commentedon May 24, 2025
Hi, any update on this?
theomonnom commentedon Jun 17, 2025
#2622