<html>
<head>
<base href="https://bugs.documentfoundation.org/">
</head>
<body><table border="1" cellspacing="0" cellpadding="8">
<tr>
<th>Bug ID</th>
<td><a class="bz_bug_link
bz_status_UNCONFIRMED "
title="UNCONFIRMED - C locale is currently broken for file handling"
href="https://bugs.documentfoundation.org/show_bug.cgi?id=125995">125995</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>C locale is currently broken for file handling
</td>
</tr>
<tr>
<th>Product</th>
<td>LibreOffice
</td>
</tr>
<tr>
<th>Version</th>
<td>6.4.0.0.alpha0+ Master
</td>
</tr>
<tr>
<th>Hardware</th>
<td>All
</td>
</tr>
<tr>
<th>OS</th>
<td>Linux (All)
</td>
</tr>
<tr>
<th>Status</th>
<td>UNCONFIRMED
</td>
</tr>
<tr>
<th>Severity</th>
<td>normal
</td>
</tr>
<tr>
<th>Priority</th>
<td>medium
</td>
</tr>
<tr>
<th>Component</th>
<td>LibreOffice
</td>
</tr>
<tr>
<th>Assignee</th>
<td>libreoffice-bugs@lists.freedesktop.org
</td>
</tr>
<tr>
<th>Reporter</th>
<td>glogow@fbihome.de
</td>
</tr></table>
<p>
<div>
<pre>Description:
This is the "extension" of <a class="bz_bug_link
bz_status_NEW "
title="NEW - Image import in KDE LibreOffice fails if filename contains non-latin characters"
href="show_bug.cgi?id=125971">bug 125971</a>.
Something in the local file URL handling is currently broken when you use the C
locale, at least on all unix backends. I can't test MacOS and Windows, but
since I suspect an error in the URL handling with regard to the current locale
setting, at least MacOS might be affected too. Has Windows some equivalent of C
locale?
Steps to Reproduce:
1. Have a unicode / UTF8 file system (that's standard I guess)
2. Have a file name with non-ASCII characters (łąka.png - 'LC_ALL=C ls -b' will
show the correct UTF8 encoding \305\202\304\205ka.png)
3. Start LO with LANG=C / LC_ALL=C
4. Open the file
5. Export the file
Actual Results:
1. The file picker for "gen" shows the wrong file names. kde5 and gtk3 are
fine.
2. After opening, the window title has the file name with a wrong encoding.
3. The recent file list has the file name with wrong encoding (which actually
works!)
4. The save dialog has the wrong default name.
5. Saving the file will generate the right file name only for gen.
For gen the wrong default on save is consequently correct and it'll ask before
overwriting the existing opened file. kde5 and gtk3 will write a new file with
a - now really wrong name.
The saved file name for gtk3 and kde5 is:
\303\205\302\202\303\204\302\205ka.png.
That's the same encoded name I would generate for the fix for <a class="bz_bug_link
bz_status_NEW "
title="NEW - Image import in KDE LibreOffice fails if filename contains non-latin characters"
href="show_bug.cgi?id=125971">bug 125971</a> via
OUString aNewURL =
uri::ExternalUriReferenceTranslator::create(m_xContext)->translateToInternal(toOUString(aURL.toEncoded()));
But this is actually some double encoding, because aURL.toEncoded() is already
the correctly encoded UTF8, which LO expects. And it's probably the origin of
most of the bug.
FWIW this is the only encoding variant LO currently accepts from either kde5 or
the gtk3 file picker.
Expected Results:
The correct filename is used everywhere, where it's now wrong in the "Actual
Results".
Reproducible: Always
User Profile Reset: No
Additional Info:</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are the assignee for the bug.</li>
</ul>
</body>
</html>