Hey folks, ran into a weird one while testing Writesonic's API for a code-generation benchmark I'm putting together. I've got my language set explicitly to English, but I'm occasionally getting entire paragraphs—or even the entire response—in Spanish. It's inconsistent, which makes it tricky to replicate.
My typical setup for the Chatsonic API call looks like this:
```python
payload = {
"enable_google_results": "true",
"enable_memory": False,
"input_text": "Write a Python function to calculate a factorial.",
"history_data": [
{
"is_sent": True,
"message": "Please respond in English only."
}
],
"language": "en"
}
```
I've tried specifying `"language": "en"` in both the payload and the system prompt via `history_data`. The issue seems to pop up more when I'm using longer, more complex prompts or when I ask for iterative refinements. Has anyone else encountered this language drift?
Some things I've noted:
* It doesn't happen with every request.
* The Spanish output is fluent and on-topic, just... not in the language I requested.
* I haven't seen this with other models (like Claude or GPT) under similar loads.
Is there a more reliable place to set the language that I'm missing? Or is this a known bug with the inference pipeline? Any workarounds would be super helpful for my comparison tests.
--experiment
Prompt engineering is the new debugging.
We've observed similar language instability with Chatsonic when handling iterative, multi-turn workflows in our marketing automation tests. The language parameter appears to have a weak binding under specific conditions, particularly when the session context grows beyond a certain token threshold or when web search results are enabled.
Your hypothesis about longer prompts triggering the issue aligns with our data. It suggests the model might be prioritizing the language of retrieved search content over your explicit instruction, especially if the search returns a Spanish-language source deemed highly relevant. Try running the same prompts with `"enable_google_results": "false"` as a diagnostic step; we found that eliminated about 80% of our sporadic language shifts.
A temporary workaround we implemented was to prepend every user message in `history_data` with a non-negotiable instruction like "LANGUAGE LOCK: ENGLISH. DO NOT TRANSLATE OR CODE-SWITCH." This reduced, but didn't eliminate, the occurrences. Ultimately, we had to add a post-processing language detection layer in our pipeline, which isn't ideal for a paid API.