Translations are coming!
by Adam Samalik
I had some discussions about translations with a few people and this is the
We have a new epic  tracking the initial implementation.
The English pipeline is quite straightforward — it takes the English source
and converts it into the English site. That already works today.
Simplified view: `English source -> English site`
The translation pipeline has a few more steps. First, we need to have a
script that converts the English sources to POT files [#114] which are used
for translations. These POT files need to be stored in a git repository
[#110] [#111] and will be consumed by a translation engine which pushes the
results back into the repo. To make it consumable for Antora, we need
another script that converts the resulting PO files into translated sources
[#115] and store them [#112] [#113] somewhere. Before the site can be
built, we also need to have a translated UI for each language that also has
a language switcher [#116] [#117]. The UI along with the translated sources
will be consumed by a build script [#119] that builds the final website.
Simplified view: `English source -> POT files -> PO files -> translated
source -> translated site`
Apart from these, we also need to have two new policies. One for adding new
content to the docs [#120] which need to ensure that the new content is
also being translated properly. The other one will be about introducing a
new language [#121] and will make sure that all the repositories are set up
and that the UI also supports this new language.
Last thing is the "edit this page" button on translated sites. For that, we
probably need to have a page for each language explaining that the content
is created and edited in English, and how translations work and how to
contribute. And the "edit this page" link (with likely a different wording)
will point to that page. There are no cards for this, yet.
So, we need places to store:
* POT + PO files for every language [#110] [#111]
* translated sources for every language [#112] [#113]
We needs scripts for:
* Converting English sources to POT files [#114]
* Converting PO files to translated sources for every language [#115]
* Converting translated sources + translated UI to the translated site for
every language [#119]
And we also need:
* Translated UI for every language [#116] [#117]
* Policy for adding new content to the docs that ensures adding it also to
* Policy for introducing a new language [#121]
As you can see, the implementation will be "translation engine-agnostic" —
using POT and PO files. This way we can have some flexibility.
I'll start working on it later this week. If you have any feedback or want
to help, let me know!
4 years, 7 months
Let's get started on Fedora 29 Release Notes!
by Petr Bokoc
It's that time of the half-year again; we're about a month from the
current planned date for Fedora 29 final release, and it's time to start
banging out release notes.
Anyone who wants to contribute should start here:
1. Pick one or more issues that have "F29" in the title.
2. Open each issue you picked, and click the Take button on the right to
claim it. (If you claim an issue but later find out you don't have time
to write about it, remove yourself from the issue ASAP so others can see
it's free and take it!)
3. Find some information about the issue. A lot of them have plenty of
info in them already; if not, find out who's responsible for the change,
and talk to them on IRC or via mail. Of course it's always better if you
try to do research before you ask questions.
4. Write a release note about the issue. If you're not sure how exactly
a release note looks, check out some of the previous releases for
inspiration. We don't want any long, overly technical texts, the release
notes are meant to highlight changes, not tell people how to use something.
5. Now the workflow diverges based on your permissions and technical skills:
5a. If you know how to use git and asciidoc, we'd appreciate if you
wrote up the release note and sent a pull request against the main repo,
branch "f29". Note that we have a different directory structure for this
release; your contributions should go into one of the files in
"modules/release-notes/pages/". Use the "build.sh" and "preview.sh"
scripts in the repository root to preview your changes locally; see the
repository README for specific instructions. If you can't see the
section where you added your contributions at all, make sure it's
included in "modules/release-notes/nav.adoc".
5b. If the above sounds like gibberish to you, it's fine: just add a
comment with your text into the issue, and ping me on IRC or through
e-mail; I'll mark it up for you and make sure your contribution appears
in the final document.
If anyone has any questions, go ahead and ask. The current schedule
shows the preferred final release target at October 23, giving us about
a month and a half. Don't count on the release date slipping :).
Petr Bokoč (pbokoc)
Senior Technical Writer
Community Platform Engineering
Red Hat Czech, s. r. o.
612 45 Brno, Czech Republic
4 years, 7 months
by amit kumar
I am Amit Sharma from Jaipur, India.I am currently looking to contribute in
Fedora community. I have been a Linux user since 2016 but this is my first
time on intending to join an open source software project since I am
confident that I already acquired necessary skills to contribute.my
computer skills level is intermediate because I can successfully install
and configure a Linux o .s.However, I can do only basic web programming
significantly to the Fedora project is user documentation especially about
installation and configuration in a desktop and laptop and also looking
forward to learn more things with you all.
Can anyone sponsor me for the group?
4 years, 7 months
Fedora/Ubuntu page in desperate need of update
by Matthew Miller
The part about sudo is very out of date (we _do_ now configure sudo by
default, and have for a very long time), and the part about dnf is a mess.
The part about "using apt anyway" should be removed, since it really doesn't
The life cycle part could be written in a more positive way, and could
emphasize ease of upgrades.
There's probably more stuff. We can talk about GNOME Shell, and also about
Fedora Server and Fedora Atomic Host / CoreOS.
So, yeah, all of that, plus of course update to new docs site and put the
wiki redirect macro in place.
Anyone interested? This'd be particularly useful for someone who does a lot
of playing with other distros. (We could use similar for Mint, Debian, and
Arch as well.)
Fedora Project Leader
4 years, 8 months
[Fedocal] Reminder meeting : Docs Writing Hour
You are kindly invited to the meeting:
Docs Writing Hour on 2018-09-26 from 10:00:00 to 11:00:00 US/Eastern
The meeting will be about:
Join members of the docs team in #fedora-docs for writing time. This is a great time to focus on writing and talk about challenges and blockers related to producing content.
There is no formal schedule for this meeting. Attendees should show up and use this as a way to block writing time into their week.
4 years, 8 months
IRC <-> Telegram Bridge
by Brian (bex) Exelbierd
I am regularly getting pulled into several Fedora Docs related
conversations in Telegram. These typically are around Antora and tooling,
but are occasionally around large areas like L10N and new doc components.
NO decisions are being made in Telegram, these are more working
I'd like us to consider setting up a Telegram <-> IRC bridge, like some
other channels have done so I can easily redirect these conversations into
the public eye and encourage greater participation.
What do you all think?
Brian (bex) Exelbierd | bexelbie(a)redhat.com | bex(a)pobox.com
Fedora Community Action & Impact Coordinator
@bexelbie | http://www.winglemeyer.org
4 years, 8 months
about the technical specifications document
by Ooyama Yosiyuki
Currently, Fedora's community has no system of writing the documents of the technical specifications.
For example, in the manufacturing industry, the work to leave technical information necessary for design for successor designers (engineers) is are incorporated into one of the jobs .
Such documents will be referred to as technical specification or design specification etc .
Applications supplied by fedora - such as anaconda and dnf - I think that the document of the technical specifications are necessary.
For example, the definition of a function defined in each application is obvious to the designer of this application, but it takes many time for a third man to understand it.
Therefore, in IT companies in general, writing a specification document is also included in the work.
I think that, Maybe Red Hat, the main sponsor company of Fedora, would have left the specifications when developing the application.
Fedora community should write the designer's specification document as well.
4 years, 8 months