<html> <head> <base href="https://bugs.documentfoundation.org/"> </head> <body> <div> <a class="bz_bug_link bz_status_RESOLVED bz_closed" title="RESOLVED NOTABUG - No KeyID for Title and Content in Slide Properties" href="https://bugs.documentfoundation.org/show_bug.cgi?id=141719#c11">Comment # 11</a> on <a class="bz_bug_link bz_status_RESOLVED bz_closed" title="RESOLVED NOTABUG - No KeyID for Title and Content in Slide Properties" href="https://bugs.documentfoundation.org/show_bug.cgi?id=141719">bug 141719</a> from <a class="email" href="mailto:serval2412@yahoo.fr" title="Julien Nabet <serval2412@yahoo.fr>"> Julien Nabet</a> <pre>(In reply to Caolán McNamara from <a href="show_bug.cgi?id=141719#c10">comment #10</a>) > (In reply to Julien Nabet from <a href="show_bug.cgi?id=141719#c7">comment #7</a>) > ... > the keyid language "qtz" isn't a true translation target with real .mo > files, but a pseudo-one implemented in unotools/source/i18n/resmgr.cxx:213, > the "if it's a key id locale, generate it here" hunk that intercepts > attempts to use the .mo file and return the keyid instead. But gtk uses the > .mo files directly to extract translations, so in keyid mode the native gtk > components continue to work on the .mos as normal. I can't think of a > practical way to the native gtk widgets to show keyid. A bit complicated but I'll put it in my personal notes and try to not forget it. > Which I suppose is an aside from the original bug which does appear to be > NAB, e.g. unzipping clippingimagestyles.pptx gives > ppt/slideLayouts/slideLayout2.xml which has <p:cSld name="Title and > Content"> in the document itself Ok so no translation possible here. Thank you for the detailed feedback!</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>