Bug Hunting Session
Bug 108894 - Update Office version in file format confirmation dialog to not refer to Office 2013
Summary: Update Office version in file format confirmation dialog to not refer to Offi...
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: UI (show other bugs)
Version:
(earliest affected)
5.4.0.1 rc
Hardware: All All
: medium trivial
Assignee: Not Assigned
URL:
Whiteboard: target:6.1.0
Keywords:
: 117165 (view as bug list)
Depends on:
Blocks: MSO-Formats
  Show dependency treegraph
 
Reported: 2017-07-02 00:16 UTC by Aron Budea
Modified: 2019-11-15 15:16 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
Writer 6.1.0 with the OOXML patch applied (10.81 KB, image/png)
2018-04-25 16:58 UTC, V Stuart Foote
Details
Word 2016 Save as type: drop list options (12.93 KB, image/png)
2018-04-25 17:01 UTC, V Stuart Foote
Details
Writer 6.1.0 Save as type: drop list with the OOXML patch applied (15.64 KB, image/png)
2018-04-25 17:04 UTC, V Stuart Foote
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Aron Budea 2017-07-02 00:16:44 UTC
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.
Comment 1 Buovjaga 2017-07-03 18:07:51 UTC
YEAH! -> NEW
Comment 2 Aron Budea 2017-07-09 15:41:25 UTC
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?
Comment 3 Tomaz Vajngerl 2017-07-09 16:03:20 UTC
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.
Comment 4 Heiko Tietze 2017-07-10 07:04:53 UTC
(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"
Comment 5 Adolfo Jayme 2017-08-21 06:24:21 UTC
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”.
Comment 6 Heiko Tietze 2018-04-10 08:52:29 UTC
Any progress here, Aron? 

(Removing UX since Tomaz suggestion is good)
Comment 7 Buovjaga 2018-04-23 12:45:23 UTC
*** Bug 117165 has been marked as a duplicate of this bug. ***
Comment 8 Commit Notification 2018-04-23 16:02:02 UTC
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.
Comment 9 Adolfo Jayme 2018-04-23 16:11:35 UTC
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.
Comment 10 Heiko Tietze 2018-04-24 08:16:42 UTC
(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.
Comment 11 Gerry 2018-04-24 19:23:35 UTC
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.
Comment 12 Adolfo Jayme 2018-04-25 02:04:03 UTC
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.
Comment 13 Gerry 2018-04-25 05:23:30 UTC
(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.
Comment 14 Heiko Tietze 2018-04-25 08:26:02 UTC
I'll put it on the meeting agenda for today.
Comment 15 V Stuart Foote 2018-04-25 16:58:37 UTC
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)?
Comment 16 V Stuart Foote 2018-04-25 17:01:15 UTC
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.
Comment 17 V Stuart Foote 2018-04-25 17:04:30 UTC
Created attachment 141633 [details]
Writer 6.1.0 Save as type: drop list with the OOXML patch applied
Comment 18 Gerry 2018-04-25 18:16:07 UTC
(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.
Comment 19 Thomas Lendo 2018-04-25 19:40:53 UTC
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].
Comment 20 Heiko Tietze 2018-04-26 14:51:51 UTC
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).
Comment 21 Commit Notification 2018-04-27 04:28:41 UTC
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.
Comment 22 Gerry 2018-04-27 04:49:01 UTC
Thanks all. This sounds like a good solution.
Comment 23 Thomas Lendo 2018-04-27 05:03:37 UTC
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
Comment 24 Adolfo Jayme 2018-04-27 05:33:32 UTC
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.
Comment 25 Heiko Tietze 2018-04-27 06:05:06 UTC
Adolfo, are you sure about "2007–2019", I mean hasn't the format stopped with 2016?
Comment 26 Adolfo Jayme 2018-04-27 06:12:14 UTC
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.
Comment 27 Heiko Tietze 2018-04-27 06:21:56 UTC
(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.
Comment 28 V Stuart Foote 2018-04-27 13:18:49 UTC
(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...