Talk:Events/FOSDEM/2013 - DevRoom - Qgil

Scratchpad

• http://toolserver.org/~emijrp/wikimediacounter/
• w:Wikipedia:Statistics
• Other slides flying around:
  • http://decafbad.com/2011/06/os-webdev-vm/slides.html

Previous page history was archived for backup purposes at Talk:Events/FOSDEM/2013 - DevRoom - Qgil/LQT Archive 1 on 2015-07-10.

If we go for an HTML based presentation framework, which one to use? Options people have mentioned so far:

• deck.js
• S5
  • See also Extension:S5SlideShow
• html5slides
• reveal.js
• dzslides
• Sozi (SVG based), used by Guillom for wikipedia-infographic.
• impress.js

(Will update as more suggestions come out there)

This post was posted by Qgil-WMF, but signed as Qgil.

Some principles thinking in the need to produce a presentation others can translate / update / extend:

• Less text = easier to translate.
• Some numbers are good: technical audience likes them; no L10n hassle.
• Too many numbers are bad: difficult to keep up with updates.
• Links are good: there is always a wiki page with more info.
• Pictures are good: we have plenty & shareable in Commons.
• Diagrams are good: publishing the sources to update or derive new ones.
• Very personal artwork is bad: difficult to evolve when the author is gone.

This post was posted by Qgil-WMF, but signed as Qgil.

• we excluded the sketch-style for the last reason (having a way to build new slides without the original author)

• There is 2 kind of slides that would need to be created: slides that support the talk, and slides that are meant to be published and read on the web

• hopefully I won't sound too pedantic saying it: most diagrams are bad, cluttered :-) And charts, well… there is even a blog dedicated to junk charts… So I feel like our goal would be to avoid as much as possible diagrams and charts, limiting them to the most simple ones. Let set some radical example here in term of clarity, legibility.

I was thinking about something like this:

• Slide 1: One word or sentence + graphic and plenty of extra space (out of the graphic or overlapping it).
• Slide 2. Copy of slide 1, adding a text paragraph.
• Slide 3: Like in slide 1.
• Slide 4: like in slide 2.
• etc...

The master is the slide set with all the slides, ready for online consumption. When it comes the time to have a presentation, the presenter only has to remove slides 2, 4, 6, 8...

Don't worry about diagrams until I come up with some data (if I do).  :)

This post was posted by Qgil-WMF, but signed as Qgil.

Before jumping into technology selections I was wondering what would be the best approach to produce slides easy to update and localize. Is there a magical combination of MediaWiki software, and http://translatewiki.org infrastructure that we can use?

With a bit of luck this presentation will serve as the basis for producing a MediaWiki project intro deck to be used by MediaWiki groups, other speakers in other events... I care less about flshy end results as long as the foundations are solid for translating the content and keeping it up to date. If we need a flashy presentation for certain relevant event then we can always work on the latest common-denominator version available.

This post was posted by Qgil-WMF, but signed as Qgil.

I don't know of good tools already existing, but if someone is interested in creating them... :)

I've not had great experiences with HTML-based presentation tools, though in theory they should be pretty cool.

Possibly the sanest thing is to do template presentations in LibreOffice/OpenOffice, save as .ODS, and either manually translate them or create a tool to extract text onto wiki pages which can then be run through the Translate extension, and used to regenerate another .ODS file. Or one might be able to work with .PPTX if you're brave. Anyway, both are zipped XML these days so it should be possible to create such tools.

Seeing brion's answer perhaps the best approach is... "there is an app for that!"  :)

I mean:

• HTML/CSS based presentation. The master is always available online and downloadable. A new downloadable package it is offered every month.
• Runs locally on last stable Firefox at full screen with flexible layout for different desktop / projector resolutions.
• Text strings are properly internationalized and handled from localization files. No need to touch HTML files for text changes. (this needs good assessment: it works for traditional application development, no idea about strings & HTML although I guess no problem with Javascript to the rescue).
• http://translatewiki.net/ is used to maintain the original copy in English and all the translations.
• http://github.com is used to maintain the master. Anybody can fork their own versions and .

eventually contribute improvements back.

• GitHub can also host the online version of the master.
• All language versions would go into a single tarball. Also the versions lite for presentations and full for online distribution.
• The speaker selects language and lite/full version in the first page of the file, then s/he gets the right sequence of slides.

Maybe someone is doing this already...

Pros:

• Easy to maintain text updates and translations.
• Everybody can install the supported Firefox version for free.
• No hassle with different resolutions with projector, etc.
• No hassle with missing / wrong fonts.
• Possibility to play with CSS & Javascript.
• Possibility to embed dynamic content from the web, multimedia...
• In case of emergency the online version is there.
• Use of great platforms for collaboration and external contributions.

Cons:

• Basic HTML skills needed to modify your own copy e.g. remove / add pages.
• "GitHub" might scare some people before knowing that it's not a big deal.

This post was posted by Qgil-WMF, but signed as Qgil.

Hi,

(I arrived here from your tweet)

About internationalization (i18n):

Many free software are using GNU Gettext to handle i18n. It uses PO files (.po extension). A PO file is simply a catalog with the original strings and their respective translation into one language. For one software, there is one PO file per language. At runtime, gettext fetches the translated strings from the catalog matching the current locale.

When we update the source code, gettext merges the changes into the existing catalogs. So translators work only on the changes (added, removed, modified). This is a golden feature. We don't want to be synchronizing changes by hand, we want the machine to do it for us, and gettext does that.

There are also various tools to help the translators to deal with PO files. http://translatewiki.net supports PO files (AFAIK).

Now can we use the same process and tools for translating documents? Yes, but not with gettext because it is a bit different. For documents we have po4a ("PO for all"). po4a can extract strings from various documents formats, and like gettext merge them into PO files. Then po4a can build translated documents from the original document and the language catalogs (PO files). See http://po4a.alioth.debian.org

I think this is what you want (more or less).

For your presentation, you probably want to define an easy-to-write source format, and from that automatically generate the presentation into the framework of your choice (HTML/CSS/JS). This source format could be for example markdown (already supported by po4a). It could also be a subset of the mediawiki format, it might make sense if people are used to it. So it would work like this:

src format ---(tool)---> HTML/CSS/JS

src format ---(po4a)---> PO files ---(po4a)---> translated src format ---(tool)---> HTML/CSS/JS

(this also allows you to change framework, without rewriting presentations)

What I am wondering is how often you will have revisions? And into how many language you want translations? Because such process and tools are good when you have many revisions, but it is a bit overkill if you just have rare updates.

Hello Luc!  :) Thank you for this feedback.

Seeing the speed of progress and the likely fact that we need to have two good presentations ready for FOSDEM in less than a month, I think I will leave aside the app + localization factors and focus in having a good and interesting set of classical slides. FOSDEM is not a deadline we can postpone.  :)

This post was posted by Qgil-WMF, but signed as Qgil.

This post by Qgil-WMF was moved on 2013-01-09. You can find it at Thread:Talk:Events/FOSDEM/2013 - DevRoom - Qgil/We have a second customer! :).

This post by Qgil-WMF was moved on 2012-12-27. You can find it at Thread:Talk:Events/FOSDEM/2013 - DevRoom - Qgil/We need a template.