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:

1. 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
   )

2. CLI Option

   • Add a command-line flag to control this behavior

   livekit-agent start --log-ensure-ascii=false

3. 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:

1. 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?

2. 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