search

fernandreu / office-ribbonx-editor

An overhauled fork of the original Custom UI Editor for Microsoft Office, built with WPF
MIT License
528 stars 104 forks source link
custom-ui excel office powerpoint ribbon ribbonx standalone word wpf

readme

Office RibbonX Editor

Downloads Release Version .NET Framework .NET Build Status Quality Gate Status

Translators welcome! See below.

The Office RibbonX Editor is a standalone tool to edit the Custom UI part of Office open document file format. It contains both Office 2007 and Office 2010 custom UI schemas.

The Office 2010 custom UI schema is the latest schema and it's still being used in the latest versions of Office including Office 2019, Office 2021 and Office 365.

To learn more about how to use these identifiers to customize the Office ribbon, backstage, and context menus visit:

Improvements

This GitHub project is a fork of Custom UI Editor for Microsoft Office. Built on Windows Forms, the original editor by Microsoft is useful on its own, but it has some limitations. Rather than trying to address those limitations by performing small contributions to the original project, this repo offers a complete redesign of the project in Windows Presentation Foundation (WPF).

Features of this overhauled editor include:

Screenshot

Download / Build status

To download the latest release, go to the following link:

https://github.com/fernandreu/office-ribbonx-editor/releases/latest

To download the latest development build instead, go to the Artifacts section on Azure Pipelines:

https://dev.azure.com/fernandreu-public/OfficeRibbonXEditor/_build/latest?definitionId=1&branchName=master

How does the Reload on Save option work?

An Office 2007+ file (.xlsm, .xlam, .pptm, .docx, etc.) is nothing more than a .zip file with a custom extension. When the Office RibbonX Editor opens one of those files, it unzips it into a temporary location first, and then it shows the content from there. To save the file, it will apply any changes to the unzipped files, and zip everything back to its original location.

The way you would use the original Custom UI Editor is similar to the following:

  1. If the file you want to edit is open in Excel, close it first
  2. Open that file in the Custom UI Editor
  3. Edit the xml files, icons, etc.
  4. Save the file in the Custom UI Editor (and close it if you wish)
  5. Open the file back in Excel, and enjoy the changes you just made

However, what would happen if you forget Step 1 and Excel has the same file open when you are using the tool? Your workflow could then look like this instead:

  1. Open that file in the Custom UI Editor
  2. Edit xml files, icons, etc.
  3. You realise you had the file open in Excel, so you close it there first
    • But you also had unsaved changes in Excel, so you save the file before closing it
  4. Save the file in the Custom UI Editor (and close it if you wish)
    • Remember: all this time since Step 1, the Custom UI Editor was looking at a temporary unzipped copy of the Excel file that did not include the changes saved in Step 3!
  5. Open the file back in Excel. The changes you made in the Custom UI Editor (Step 2) are there, but the ones you did in Excel (Step 3) have disappeared

The Reload on Save button adds an extra step to the process as a safety precaution in this scenario. In essence, Step 4 will no longer use the temporary unzipped copy of the Excel file that was generated in Step 1, but will generate a new one instead. As a consequence, any external changes you might have done in the meantime (i.e. Step 3) will no longer get lost. If you did not make any external changes, the Reload on Save button won’t have any noticeable impact for you.

Do you want to see the tool in your language?

Any help improving existing translations or adding new ones is welcome. I will add your names to a list of acknowledgments, either in this readme or in the About section of the tool itself.

Improving an existing translation

If you get stuck in any step, feel free to create an issue and I will assist you.

  1. Find the file you want to edit on this GitHub project
    1. All translations are Strings.xyz.resx files stored in src/OfficeRibbonXEditor/Resources
    2. The xyz part is what indicates the language contained in the file
    3. For example, the Spanish translation is stored in the Strings.es.resx file here
  2. Click on the Edit button at the top-right corner
    1. This might trigger a fork of this project under your GitHub account (otherwise, it will occur when saving any changes)
  3. Make any necessary changes
    1. The <data> tags are essentially the string resources throughout the application
    2. Their name attribute is how they are being identified internally. This might provide some hints about their intended use
    3. Otherwise, there might also be a child <comment> tag providing more details about a particular resource
    4. Only the child <value> tags should need modifications
  4. Save the changes at the bottom
    1. This should trigger a commit of the file in your forked repository, and perhaps a pull request to this repository too
    2. If the pull request does not occur automatically, you might see some buttons either in your fork or here to do so

Creating a translation for a new language

These steps are recommended for people that are already a bit familiar with the Git / GitHub workflow. If this is not your case, please create an issue instead. I will then generate a template myself, so you will be able to follow the previous steps instead of these ones.

  1. Create a copy of the Strings.resx file here, which contains the default English language
    1. If you want, you can also create the copy from an existing translation (e.g. Strings.es.resx for Spanish here)
  2. Name the copy Strings.xyz.resx, with xyz being your language tag
    1. For a list of available language tags, see the table in this page
    2. There is no need to specify the country in the language tag as well (i.e. de, pt, ru, etc. is enough)
  3. Put the file in the same src/OfficeRibbonXEditor/Resources folder where the original file was
  4. Make any necessary changes to this file
    1. The <data> tags are essentially the string resources throughout the application
    2. Their name attribute is how they are being identified internally. This might provide some hints about their intended use
    3. Otherwise, there might also be a child <comment> tag providing more details about a particular resource
    4. Only the child <value> tags should need modifications
  5. Modify the LanguageChoice class here to add your new language into the All collection

It might be possible to perform all these steps directly in your GitHub fork via several commits. Otherwise, you might need to have at least Git installed. Visual Studio should not be necessary unless you want to see how your translation looks (you will be able to see it from the build artifacts of your pull request too).

Special thanks to all translators so far

Code Signing

The tool is no longer being signed using a certificate from a trusted root certification authority. Instead, each build now uses a temporary, unique code signing certificate. Those will be signed using the following self-signed certificate:

This will give issues with Microsoft SmartScreen, but you should be able to skip any warnings. If you are unsure if you should skip those warnings, there are a couple of things you could check:

For more information, see #185.