New Edition

Introduction

Fedora editions are "versions" of Fedora that users can install. These include "official" editions (Workstation and Server at time of writing), but the ultimate goal in Websites is to also make Spins and Labs editions be considered "editions" in some form as far as websites are concerned. That is to say, we’d like to ultimately have Spins and Labs have a section on the main getfedora.org site, rendering https://spins.fedorparoject.org/ and https://labs.fedoraproject.org/ useless and able to be gotten rid of. Doing this effectively will take some time.

Also note that most of the content in this document applies to adding pages in general, with the notable exception of the release.yaml edits. Adding a page to getfedora.org should follow largely the same process, though.

All new editions should be added to getfedora.org, to aid in our goal of getting rid of all of the *.fedoraproject.org edition-specific subdomain sites. This generates a more consistent and less confusing user experience and makes maintenance of the websites easier going forward. Everything in this document assumes that you are working with the getfedora.org codebase, and NOT creating a new site from scratch.

Now then, all work in this document takes place in the repository in which getfedora.org lives, and particularly in the sites/getfedora.org/ directory.

Edition-specific Release Variables

The first step is to edit release.yaml, and add the relevant sections under ga and beta for your new edition. Use workstation and server as templates. You might not need all variables that these existing sections have, or you might need to add new ones, depending on your templates, but these blocks should get you started.

Exporting the Edition Routes

Now, open main.py and go to near the bottom, where you’ll note a number of export_route(…) calls. This method is a custom method defined earlier in the file, which does a little bit of work for us: The first argument is an internal identifier name, so that we can reference the page using url_for safely (if the URL changes, so will the URLs that get generated by url_for). The second argument is a path to the directory that contains the templates you’ll make, but with a preceding and trailing /. Follow the example of the other, currently existing pages and add the appropriate export_route calls at the end.

Hacking the Templates

The templates themselves live in the sites directory (under sites/getfedora.org/ still). There are already templates started (but not currently exported in main.py) for silverblue, coreos, and iot, at time of writing.

Every string you add must be enclosed in {% trans %} … {% endtrans %} blocks so that it can be translated. If the string spans multiple lines (we tend to break at 80 characters but are fairly lenient about this), then the opening block should instead be {% trans trimmed %} (the closing block is still just {% endtrans %}).

You can copy the templates from the existing editions, if you need inspiration or help.

Letting the Translators Do Their Thing

Once the above is done, the next step is get all the strings in the hands of the Fedora Translations team. If you have an account on Fedora’s Zanata instance, and are in the appropriate websites group on Zanata, and have a valid ~/.config/zanata.ini file, you can do this step yourself. Otherwise you’ll either need to be added to the appropriate team or have someone do this for you:

Run ./scripts/translations-source.sh. At the end of its output, it will give you the Zanata command to push the strings up: zanata push getfedora.org.pot

Concluding

Largely, that is it. You’ve added variables that are easy to update each release (in release.yaml), you’ve exported the pages, written your templates in a translatable way, and pushed those strings to the Translations team. Now you can sit back and relax while the translators do their thing. Their translations will go live immediately (well, within an hour) and automatically.