Giuseppe, Thank you for this very long explanation, it helped me to understand your position (not that I didn't understand it before, but it's nice to be sure). I'll try to put down there why I think you're wrong, if you still need after this for me to do a line-by-line commentary of your message I'll do it (but I'll spare the list a very long message for now).
Your core assumption seems to be a single person or group controls the document, and as such they'll be able to agree on several conventions, the core one in our case being changing the language attribute in a style is forbidden once the text has been typed (this is where I challenged you writing if the UI does not block this some people will do it, and where you replied me you didn't see why one would be as dumb as do it with his own document). This assumption is utterly wrong. Companies do not maintain in-house teams of translators. When they have to produce a multilingual document the translation parts are subcontracted. Most often they're subcontracted to a translating office which is supposed to know all the required languages. Actually such a thing does not exist - the translating company just sub-contracts each language to a different freelance translator. Forbidding him to talk to the original customer, as they like to maintain the fiction they're this big translating office that can do any langage you need (smart customers accept no such thing exist and work directly with the freelance translators - it's cheaper and the result will be better, as your translator can ask you questions when he's not sure of your meaning) All the document formatting work is done by one team (in the original company) which knows next to nothing about language needs. All the language work is done by other people which know little about formatting and can not talk to the first team. This should not matter as translation is content and formatting is presentation. Indeed once the translated document is returned by the translator he may never hear about it again. But the document still lives. Original company may decide to merge it with other documents it got. It may decide to reformat it for release on another support. It may have its graphical charter changed (been bought, bought someone else or just wants to change its image). In all these cases the company will just take its multilingual document, dump it on the formatting team, and ask them to re-style it. The content does not change after all, why should they spend money again to get translators work on it (and even if they did spend the money there's a fairly high possibility they'd end up with a different team than the first time). The current OO.o behaviour, and the one you propose, breaks this content/presentation separation. Styling people can utterly destroy the langage hinting of a document just by being not careful - and why should they be careful, langage is not part of their job. By putting language controls in the presentation parts of OO.o, you actually encourage them to wreak havoc on this hinting. At this point, I don't care what the final solution is. I've proposed one, better people than me can decide on another. But one thing I'm 100% sure of - language and presentation must be separated because they are separated in real life. The internal OO.o plumbing may treat them the same way, but the OO.o UI must make sure presentation and content controls are separate and independant, so the people who work with content and the people who work with formatting can do their job without making each other life miserable. The BIG difference between your proposal and mine, is conditional styles do not touch language. They do all the fancy formatting you may need, but the original content is left alone. Which means next time there is a ยง to add to the document, translators will find a correctly hinted text, not something messed out by presentation-oriented restyling. Regards, -- Nicolas Mailhot
