Currently the Confirm File Format dialog displays something like this: "This document may contain formatting or content that cannot be saved in the currently selected file format “Microsoft Word 2007-2013 XML”." The confirmation button also reads "Use Microsoft Word 2007-2013 XML Format". Since Office 2016 has been out for a while, we should update our texts to reflect that.
YEAH! -> NEW
The change to include 2013 was this one: http://cgit.freedesktop.org/libreoffice/core/commit/?id=a01605430ec6124093d3b4896839b1bf65c071ed As Andras noted in bug 72034 comment 3, a more concise wording would be needed in the future... maybe instead of "2007/2010/2013/2016" use "2007-2016"? Possibly also changing the name of binary format to a similar range, "97-2003". UX team, what do you think?
Actually I would say "2007 and newer" or something like that. I don't think it makes sense that we need to update every time a new version of MSO is released.
(In reply to Tomaz Vajngerl from comment #3) > Actually I would say "2007 and newer" or something like that. I don't think > it makes sense that we need to update every time a new version of MSO is > released. Good idea. And in case MS reinvents the wheel we can update to "2007-2020" and introduce "2020 and newer"
I think we should just drop the numbers from the XML* filters (as Microsoft Office does) and just label the binary filters “97–2003”, as Áron suggested. * And oh, they should be labeled “OOXML”, not “XML”.
Any progress here, Aron? (Removing UX since Tomaz suggestion is good)
*** Bug 117165 has been marked as a duplicate of this bug. ***
Adolfo Jayme Barrientos committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=195e12bdc516c9272b7ae353ad6279e457215911 tdf#108894 Drop Office version numbers in filter names It will be available in 6.1.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
I didn’t use “and newer” because that would blow up even more the size of the strings when translated. With my patch, our translators won’t need to re-translate these names over and over, each time new Office versions come up.
(In reply to Adolfo Jayme from comment #9) > I didn’t use “and newer” because that would blow up even more the size of > the strings when translated. With my patch, our translators won’t need to > re-translate these names over and over, each time new Office versions come > up. OOXML sounds good to me though not sure if MSO users who think in years can follow this precision. But to refrain l10n from unnecessary work I agree with you.
OOXML sounds IMHO way too technical for end users. For this reason, I think the solution of the commit is not a good solution. I don't know any Microsoft Office user who knows what "Microsoft Word OOXML" is. Users will be confused, because they want to save the file as Word 2016 or Word 2013 etc., but they will not be able find this option in LibreOffice! I find following option the most precise and most understandable: Microsoft Word 2007-2016 OOXML With this option, there would be no need for localisation. The Office 365 users would be still able to identify this filter. The only minor issue would be that LibreOffice developers have to update these ten strings to the most recent MS Office version. P.S. I felt free to set this bug to REOPENED. In case you disagree, please change it back to resolved.
Because “XML” alone wasn’t geeky at all… Come on. > With this option, there would be no need for localisation. Es obvio que no hablas otra lengua.
(In reply to Adolfo Jayme from comment #12) > Because “XML” alone wasn’t geeky at all… Come on. Adolfo, thanks for your comment. However, it really misses the point. What I am saying is that the previous solution was far superior to the new fix. The previous solution was: "Microsoft Word 2007-2013 XML" and my suggestion is to update it to: "Microsoft Word 2007-2016 OOXML" or "Microsoft Word 2007-2016 (.docx)" Only this would guarantee that Microsoft Office users will be able to identify the correct filter. Many of them will *not* be able to do so if the filter is called "Microsoft Word OOXML", because they have no clue what OOXML is. They want to save the file as Word 2016 or Word 2013 etc. That's the terminology which they know.
I'll put it on the meeting agenda for today.
Created attachment 141631 [details] Writer 6.1.0 with the OOXML patch applied The attached clip shows a Writer document Save As drop list. The whole thing seems kind of muddled, and why are we giving so much free space to Microsoft? Anyhow, are the new Microsoft Word OOXML (.docx)(*.docx) and the Office Open XML Text (.docx)(*.docx) the same export filter? Or not (and the filter can produce OOXML Strict)?
Created attachment 141632 [details] Word 2016 Save as type: drop list options Compare the attached Word 2016 list of save as types to the LibreOffice list and we are really doing ourselves no favors with our naming.
Created attachment 141633 [details] Writer 6.1.0 Save as type: drop list with the OOXML patch applied
(In reply to V Stuart Foote from comment #16 and comment #17) Thanks V Stuart for the screenshots. Particularly the MS Word screenshot is very illustrative. Probably the easiest solution is also the best solution to import/export the current MS Office file formats: "Microsoft Word (.docx)" ... Thanks.
I prefer wording that users are familiar with in other programs: Word Document (.docx) Word 2003 XML Document (.XML) Word 97-2003 Document (.doc) Strict Office Open XML Document (.docx) or Office Open XML Document (.docx) [1] I don't see the benefit for a year in current Word OOXML file description (regardless what exact OOXML form it is as users don't know it). Stuarts question in comment 15 is also important for [1].
We discussed the topic in the design meeting. OOXML is not common in the Microsoft world, the term Microsoft is too much advertising (and not used in Word), so the recommendation is to use "Word 2007-2016 (*.docx)" The entry "Office Open XML Text (docx)" is in fact an extra filter but orthogonal to "strict". However, it can be hidden in the menu to not bother users (see ESC minutes for this).
Adolfo Jayme Barrientos committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=3fae9479d7c95d1ef2b4b406c7a856cbe9c402ac tdf#108894 Implement suggested filter names It will be available in 6.1.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Thanks all. This sounds like a good solution.
Is the term Autoplay missing? --- a/filter/source/config/fragments/types/MS_PowerPoint_2007_XML_AutoPlay.xcu +++ b/filter/source/config/fragments/types/MS_PowerPoint_2007_XML_AutoPlay.xcu @@ -22,6 +22,6 @@ <prop oor:name="MediaType"><value>application/vnd.openxmlformats-officedocument.presentationml.slideshow</value></prop> <prop oor:name="Preferred"><value>true</value></prop> <prop oor:name="PreferredFilter"><value>Impress MS PowerPoint 2007 XML AutoPlay</value></prop> - <prop oor:name="UIName"><value xml:lang="en-US">Microsoft PowerPoint OOXML</value></prop> + <prop oor:name="UIName"><value xml:lang="en-US">PowerPoint 2007–2019</value></prop
This file has never included it; see the patch where it was first introduced: https://cgit.freedesktop.org/libreoffice/core/commit/filter/source/config/fragments/types/MS_PowerPoint_2007_XML_AutoPlay.xcu?id=ddb579355d9be06bf15e50ac0d20e544eaa8e953 If it’s an error, please file a separate report.
Adolfo, are you sure about "2007–2019", I mean hasn't the format stopped with 2016?
We are compatible with Office 365, which is like a rolling (Arch Linux release model) version of Office. We are compatible with 2019, and I’m not introducing translatable strings that will become stale in less than a month after 6.1 gets released.
(In reply to Adolfo Jayme from comment #26) > We are compatible with Office 365, which is like a rolling (Arch Linux > release model) version of Office. We are compatible with 2019, and I’m not > introducing translatable strings that will become stale in less than a month > after 6.1 gets released. Okay, fine for me. Many thanks for doing the work.
(In reply to Adolfo Jayme from comment #26) > We are compatible with Office 365, which is like a rolling (Arch Linux > release model) version of Office. We are compatible with 2019, and I’m not > introducing translatable strings that will become stale in less than a month > after 6.1 gets released. Yes, probably correct to label filters for it now given MS announced "Office 2019" release "sometime in 2018". But, always some possibility that additional filter work for future Office 365 / 2019 becomes necessary as MS "extends" OOXML and we end up needing another entry for it. Good catch Adolfo...