Hi, I work on translation of the LibreOffice guides to Slovak. I use for that the OmegaT translation tool, because it can read and write odt files. I observe a problem, which can be perhaps solved by adding a new function "Clear Direct Character Formatting" along to the existing "Clear Direct Formatting". The problem: OmegaT (and other similar CAT tolls) breaks text in sentences, which are then translated. It honours formating, which means that the translator sees the formating tags (in OmegaT they are abbreviated e.g., to <f1> text </f1). If there is too much of direct formating, the text becomes untranslatable by CAT tools, because tags appear everywhere and also inside words. This is exactly the case of the LO guides. The remedy for this is to use styles and then to remove the direct formating. The problem is that "Clear Direct Formatting" removes all direct formating - in the case of LO guides it breaks headers, lists etc. The reason may be that the guides were not written "the right way". However, even authors of the LO guides do not use LO "the right way". I think that introduction of the "Clear Direct Character Formatting" (cleaning up stuff only inside paragraphs withou influencing the rest) would solve this problem. It will make translation of odt files by CAT tools possible. I currently use a workaround for that: I unzip the odt file and clean the content.xml file by my own python script. It does not work perfect but still solves the problem. The proposed solution would make possible to translate odt files for all. Thanks for considering this proposal -- Milos
Seems like a reasonable request, especially as there is a clearly indicated use case. Status set to NEW.
What you ask for exists in Apply Style dropdown as "Clear formatting". But, it's not so obvious, especially that it's different from Format - Clear Direct Formatting, so I'd also like to have it added to Format menu.
(In reply to Milos Sramek from comment #0) > The problem: > OmegaT (and other similar CAT tolls) breaks text in sentences, which are > then translated. It honours formating, which means that the translator sees > the formating tags (in OmegaT they are abbreviated e.g., to <f1> text </f1). Do you have a sample file and/or screenshots? It would help document and understand your use case better. > The problem is that "Clear Direct Formatting" removes all direct formating - > in the case of LO guides it breaks headers, lists etc. The reason may be > that the guides were not written "the right way". However, even authors of > the LO guides do not use LO "the right way". I tried to reproduce it: I created a new document with sample text and applied lists (both, directly and by list styles) and a header. I did "Select All" and tested both "Clear Direct Formatting" and "Clear Formatting" from the "Apply Styles" dropdown [*]. The result was: lists and headers were kept appropriately. So I could not reproduce in LibO 5.1.3.1 on Debian Sid. Maybe the "not using the right way" is getting in between? Can you point us to a sample problematic guide? [*] "Clear Direct Formatting" does what it says: it clears just direct formatting (direct paragraph, character, etc.). OTOH, "Clear Formatting" from the dropdown will clear all direct formatting *and* set character styles to Default and paragraph styles to Text Body. > I think that introduction of the "Clear Direct Character Formatting" > (cleaning up stuff only inside paragraphs withou influencing the rest) would > solve this problem. It will make translation of odt files by CAT tools > possible. I am also of the idea that "Clear Direct [__styletype__] Formatting" should exist somewhere.
Definitely useful UNO commands that could one day go into a group/split button for users to be more precise with what they want to do.
Clear direct formatting (CDF) removes the character and the paragraph attributes that are applied directly. CDF does not affect styles such as lists, page, character... If styles were used properly in the document CDF wont "break headers, lists etc.". My take: WF/NAB
*** Bug 71233 has been marked as a duplicate of this bug. ***