[Closed] Gutenberg Translations Not Applied Due to Encoding Mismatch

## Environment

- WordPress Theme with custom Gutenberg blocks
- WPML + WPML Page Builders extension
- Custom blocks using standard WordPress `RichText.Content` components
- `wpml-config.xml` with `` and XPath configuration

---

## Problem

Translations for custom Gutenberg blocks exist in the WPML database and are marked as **"complete"**, but they are **not applied** to the translated post content. The original (source language) text is displayed instead of the translation.

---

## Root Cause

There is an **encoding mismatch** between how WPML stores extracted strings and how it searches for them when applying translations. WPML modifies the string during extraction (adding characters, decoding entities), but during translation application it searches for the modified version which doesn't exist in the actual post content.

---

## Evidence

### Hex Dump Comparison

We compared the exact bytes of a string stored in WPML vs. the actual post content:

```
WPML icl_strings.value ends with: 6572207365696e2e c2a0 ("er sein." + NBSP)
Actual post_content ends with: 6572207365696e2e 20 ("er sein." + space)
```

**WPML adds a trailing non-breaking space (`xC2xA0`) that does not exist in the original content.**

### Database Verification

```sql
-- Translations exist and are marked complete (status = 10)
SELECT s.value as original, st.value as translation, st.status
FROM wp_icl_strings s
JOIN wp_icl_string_translations st ON st.string_id = s.id
WHERE s.context LIKE 'gutenberg-%'
AND st.status = 10;
```

Translations are in the database but never applied to the post.

---

## Affected Characters

| Character | In post_content | What WPML stores |
|-----------|-----------------|------------------|
| Trailing space | ` ` (0x20) or none | `xC2xA0` (nbsp added) |
| Ampersand | `&` | `&` (decoded) |
| Non-breaking space | ` ` or ` ` | `xC2xA0` (UTF-8) |
| En-dash | `–` | `–` (decoded) |

---

## Steps to Reproduce

1. Create a custom Gutenberg block using `RichText.Content`
2. Add text with special characters, e.g.: `"Sauberkeit & Hygiene"`
3. Configure the block in `wpml-config.xml`:
```xml

//div[@class='text']

```
4. Save the post (WPML extracts strings)
5. Create translation, translate the string, mark as complete
6. View the translated post
7. **Result:** Original German text is displayed, not the French translation

---

## Expected Behavior

WPML should apply translations that are marked as complete. The encoding used during string extraction should match the encoding used during translation lookup.

---

## Workaround

We implemented a workaround that tries multiple encoding variants when applying translations:

```php
$variants[] = $string; // original
$variants[] = str_replace("xC2xA0", ' ', $string); // nbsp → space
$variants[] = str_replace("xC2xA0", ' ', $string); // nbsp → entity
$variants[] = preg_replace('/xC2xA0+$/u', '', $string); // remove trailing nbsp
$variants[] = str_replace('&', '&', $string); // encode ampersand
```

This workaround should not be necessary.

---

## Requested Fix

Please ensure consistent encoding handling: strings should be stored exactly as they appear in post_content, or WPML should try encoding variants during translation lookup.