For example, you might be able to read and understand a foreign language website sufficiently using machine translation (like Google Translate), but machine translation is mostly not sufficient for contributing own content to it. So what? The optimum case would be to have a webservice that offers instant translation for small texts. Or translation with a short turnaround time like one hour, after which you can insert your statement into the website or forum. Ideally, such a webservice would be P2P organized: you would earn credits by doing this instant translation for others, and would spend them for getting own translation.

Funny enough, this exact thing does not exist. Here's what I found instead, by adequacy, starting with the best solutions:

  • Fiverr. So far the best solution I could find for cases where you don't need super professional (just understandable) translation quality. You will easily find people offering 500 – 1000 words of translation for 5 USD. Turnaround time can be as fast as 24 hours. Or try to make a special deal with somebody offering translation, language lessons or similar, so that you agree on a time to chat where you can get the translation right away, or agree that you can send multiple e-mails with short texts which the translator will translate immediately or within a day, up to a total word amount.
  • SpeakLike Chat Translation. Indeed they do realtime translation in chats, and by chatting with yourself on two accounts you can of course intercept the translation for putting it into a webpage lateron. Price is about 0.05 EUR/word [source].
  • SOS Translator Chat. They offer live translation by instant messaging with a translator. They charge a start rate plus a rate per minute, not per word [source]. So this is rather difficult to fit in for contributing content to a website.
  • VerbalizeIt Skype-embedded translation. It seems they offer text-to-text realtime translation for Skype chats. However it's a professional service, so it's not cheap, seemingly starting at 0.17 USD/word [source].
  • ackuna. Nice idea: a crowdsourcing site for translating. You translate something for others, and you can get something translated by others. However there is no system where you have to earn points by translating before you can get something translated, so from a first glance it seems that you can't count on your text being translated in reasonable time. It can take months. Also, the site is mostly for short phrases as found in software applications – while it's possible to enter paragraphs of text, this will probably quickly overchallenge the goodwill of the uncompensated volunteers. The site also accepts special file formats for software i18n, but is not limited to that: there's also a textbox to paste the text you want translated [source, at "How do I create a project?"] I have to admit that I don't like the translators' interface of Ackuna too well: it's a good start, but for great usability a lot of tweaks have to be made. Like translating in lists (with tabbing), AJAX voting in lists (saving more page load times), a transactional one-point-per-word system where people have to earn points by translating before posting own projects, showing only entries without any submission while translating, etc..
  • Transfix.it. A software where humans proofread and fix machine-translated texts.
  • WikiTranslation. A site for gratis, community-generated translations which can be voted.
  • OneHourTranslation. Fast turnaround time of at most one hour to start and one hour per 200 words. But mostly too expensive for private use in forums etc. (0.06 EUR/word).

Some other interesting finds about translation include:

  • Linguanaut Free Translation. Translation is done by volunteers. Which means they are of course not compelled to do the job, there is no deadline, and one can't be sure when the job gets done. But for occasional, not time-critical translations it seems great. Not a good idea to exploit volunteer with high volume work, of course.
  • Free human translation at Translatorsbase.com. Only for single words and short phrases, but for these really useful. The translators get higher ranking by providing such free translations.
  • Gengo. Offering people-powered translation services.
  • Babylon Human Translation. By well-known translation software provider "Babylon".
  • TYWI Mobile Interpreter. Offers simultaneus human translation of speech, via a professional translator, connected by Internet.
  • Wikipedia on Telephone intepretation.

This is my commentary on the analysis of monetary inflation and income development by Dr. Harald Wozniewski, as presented on kiwifo.de, especially on page "60 Jahre Währungsreform –
60 Jahre Geldmengenwachstum
".

Our task is first to determine the real inflation rate (not by means of a shopping basket, which is hedonically corrected etc.). This is simple: If the inflation rate grows only as much as the GDP, its speed of circulation stays the same, so also the "difficulty of aquiring money", so also the prices. Because, circulation speed is the ratio of GDP to money: Circulation speed of money = GDP / (M1 + cash). If this speed decreases, there is more money, and this means price inflation. This price inflation can however be hidden by the fact 

However, all this money is created by monetization: banks have securities in their books, and emit their own securities based on that, some of which (plus public bnonds) are accepted by the central bank. So other banks can borrow them, place them at the central bank, and get cash money delivered in return. So higher monetization is only an indicator of credit expansion (potentially made possible by wealth accumulation as goods, like real estate that banks can use as securities). But still, by allowing this increase of monetization, teh central bank allows the same amount of inflation. Which, minus the GDP growth, means the same devaluation of wages, which are paid in this money.

We see: Economic exclusion because of money scarcity does not happen because there's too little money in the system (teh opposite is the case). Instead, because this money is not paid as wages.

Measuring the GDP increase year by year, after deducting shopping-basket based inflation, measures efficiency gains, and in one sense this is indeed the growth of the economy: more wealth because of more efficient tech. These efficiency gains normally have to be forwarded to the workers by wage increases that are the same as GDP growth (to keep mass purchasing power). But what GDP change does not account for is, what proportion of this total wealth is available for purchase from a worker's income. This proportion steadily decreases because the monetary amount is more inflated than the GDP. In total, the "right of one EUR to a proportion of total GDP" has decreased by 74.3% from 1970 to 2012 [source, "Tabelle 2".U53]. Of course, the "right of 1% of total money amount to a proportion of total GDP" has not decreased, but to keep their income at the same proportion of the money amount, the income of workers would have to increase by the same amount as monetary inflation. Which it did not.

This does not mean that workers are now, in absolute terms, worse off than in the 70's: theres (1) profiting wealth accumulation because a house etc. can be used for decades, and (2) profiting from the increase of total wealth through advancement of technology. That's why German workers don't complain as much as they should. But in relative terms, they are much worse off: the entitlement from their monetary income to a proportion of the yearly produced total wealth ("GDP") in 2012 was only 25.7% of what it was in 1970.

This does however not necessarily mean that prices are four times higher than they should be if worker's would fare as well as in 1970 (or that workers would have to earn 4 times as much). It just means that, as they have less right to total wealth with their income, someone else has more right. But, as can be seen from the decrease of monetary circulation speed by 74.3% as well, they do not use that right, they just have it stored as money. Prices do not increase by monetary inflation automatically, but only if the circulation speed of the money decreases less than it is inflated. If those who have the addictional money would (could) use it as often as in the 1970's, that would of course lead to a fourfold price increase. But this is not even possible except as a one-time effect: their right to this money does not replenish as continually earned wages do (it only replenishes by interest), so the two cannot be compared easily.

So it is not justified from these findings of monetary inflation to say that workers don't earn their fair share (that may be found nonetheless from other arguments!). Instead, if anything, then the monetary inflation amount that is beyond real wage increase rate (which means 10%, as since the mid 90's there were no real wage increases) is a sum of money that is year by year distributed to "others" (banks, companies, privateers) while it should be distributed to the workers. This is for example 200 billion EUR from 20011 to 2012 [source, "Tabelle 2".M52-M53]. Distributed to 68.4 million adults in Germany (data form 2011-01), this would mean an added income of 2923 EUR yearly. Instead, it accumulates "somewhere else".

So what we have here is a phenomenon of wealth accumulation in money that was not there in earlier years. But since money is only a small part of a nation's accumulated wealth, it is by no means sufficient to look at monetary wealth accumulation alone to determine a problem with wealth accumulation in Germany. Instead, one has to look at total assets.

So, in my conclusions, the arguments by Dr. Harald Wozniewski are internally misguided. Still, lots of interesting figures to find there from which you may draw your own conclusions.

One of my latest projects was setting up the Git source code management system on a customer's server, so that different developers can have different access rights to repositories. How to do that?

For the really simple case of one set of repositories with r/w access to every developer in your organization, you can use a git server, with or without a dedicated user, with or without SSH keys [source]. For the complex case with even intra-repository rights management, there is Gitolite; or Gitosis, but that is no longer maintained [source]. But what is the simplest solution for the middle ground: multiple users, and giving each one access to a potentially different set of repositories?

Here's a solution for that – I haven't seen it documented anywhere, but I guess it's quite obvious. I simply extend the outta-the-box git server scenario by running multiple git servers in parallel, each for one (non-intersecting) set of repositories with one (potentially intersecting) set of developers who get r/w access. So for example, you can have a setup like this:

  • team 1
    • repositories: project 1, project 2
    • developers with access: Alice, Bob, Andrew
  • team 2
    • repositories: project 3
    • developers with access: Alice, Juan
  • team 3
    • repositories: project 4, project 5
    • developers with access: Juan

Setting up a team

For every team, you set up one dedicated user and git server on your host. You can have as many servers as you want, and adding one always follows this procedure. Let's assume we want to set up a team devteam1.

  1. Create a new user and set a password for it. Say you want to name the user devteam1, then execute: adduser devteam1.
  2. In /etc/passwd, change devteam1's shell to be /usr/bin/git-shell (or wherever it is on your host – see which git-shell). This prohibits SSH access with this user, but allows git commands.

Adding a developer to a team

Say you want add developer Alice to your team devteam1, which means giving her r/w access to all repositories of devteam1. The simplest solution is to hand out the password for system user devteam1 to the new developer. This requires however to enter it on every commit. (If you want to avoid this, the usual and widely documented method if to use SSH keys with git.)

Note that using one shared user account for writing to your remote repository does not mean that commits from all the developers will use the same author information. Instead, the password needed for git push just is for transferring your commits. Your commits have been made earlier, in your local git repository, using the author information configured in git.

You can determine git's author information by looking at user.name and user.email in git config --list (potentially overwritten in environment variables GIT_AUTHOR_NAME and GIT_AUTHOR_EMAIL [source]). You can configure this author information for your user in ~/.gitconfig on your local computer, and if needed override it in .git/config per repository, by adding a section like this there:

[user]
        name = Alice Example
        email = alice@example.com

Adding a repository to a team

Say you want to add repository project1 to team devteam1. On your server, do this:

  1. cd /home/devteam1
  2. mkdir project1.git
  3. cd project1.git
  4. git init --bare
  5. chmod -R u=rwX,g=rX,o= .
  6. chown -R devteam1:devteam1 .

Explanations:

  • git init --bare creates a "bare" repository, which means one that stores all the code in objects, but without having a working directory (the set of source files a developer will work with on her local computer). On your local computer, the git repository resides in a .git subdirectory, while a "bare" repository is created in the current directory, not within a .git one.
  • The chmod and chown commands make sure the devteam user is the one with write access to the repository; else, git push commands involving this repository (using devteam1@example.com:/home/devteam1/project1.git) would result in this error message: "error: insufficient permission for adding an object to repository database ./objects" [source]. They also make sure no other user has access, not even nread access.
  • Note that read and read/write access to git repositories on the server is controlled by the file permissions of this repository's files. So rights management is effectively just Unix system file rights management: Every Unix system user with read access to these files can be used in a git command to read (clone and pull) the repository. Every Unix system user with write access can be used in a git push command. So if you want to create a world-readable repository, make its files world-readable. If you don't want the simple "team -> repositories" hierarchy we use here, you can instead create a group with r/w access for every repository on the server, a system user per developer, and add that user to all groups of repositories that you want him / her to access r/w.

Working with your repositories

Say you want to access a repository project1 that belongs to devteam1, and your server is example.com:

  • Cloning the git repository to your local computer: git clone devteam1@example.com:/home/devteam1/project1.git. This creates a local directory project1. Go there and do your changes to your code.
  • Getting and merging changes from the repository: git pull.
  • Committing your changes to the repository: git add .; git commit -m "Commit message."; git push; You will be asked for the password of user devteam1 on the server.

Here's my collection of favorite DNS tools and techniques to troubleshoot issues:

This is so far just a proposal – I did not fully test it out yet, but have exlored options for two days and this seems best, for my requirements. (And thanks to mantas in the comments, whose tip for Docear lead to this major rework of an earlier article, which was using Freemind instead.)

Requirements

  • literature database, with both metadata and fulltexts
  • adding to the literature database collaboratively, synced to everybody in a group
  • creating notes right when reading
  • creating notes on documents collaboratively, synced to everybody in a group
  • flexible means for organizing note collections, with links to the part of the annotated document
  • visually navigable documents when writing (no, not TeX or HTML source)
  • ability to draft scientific articles and theses in a mindmap-style, "notes organizing" mode
  • ability to write scientific articles in WordPress
  • ability to write scientific articles in LibreOffice, with easy web publishing both as HTML in a WordPress site, and as PDF
  • automatic creation of a references list when writing, both in WordPress and LibreOffice
  • both web-published (HTML and PDF) and local versions shall have working hyperlinks to cited works, including links to the page
  • tools should work cross platform (Linux, Windows, Mac)
  • free and open source software as much as possible

Solution Proposal: Docear + Zotero

Tool collection

My proposal uses the following tools, which you should install (available for both Windows and Linux):

Workflow

[TODO: Show how to use Dropbox or an open source replacement for it to sync your (cited, and only those) fulltext files with annotations to your server. And how to password-protect those fulltext files that cannot be published to everybody, using an efficient command that adds to a .htaccess file.]

  1. Document collecting. Whenever you find an interesting document on the web, use the Zotero browser plugin to create a literature entry in your Zotero group. Use tags to mark documents you have read and want to read. Create attachments to the entries, linking to the online fulltext of these articles.
  2. Finding what to read.
    1. Use your Zotero browser plugin or standalone application to browse through your group's shared bibliography and select items you want to read.
    2. Download them with Zotero to your "Literature" directory and name them according to their key in Zotero, plus your author shortname (example: Gantt2001.matthias.pdf). This is because this file will contain your annotations, and files with other author suffixes will contain their annotations.
    3. Add a (hypothetical) web links to your annotated file as attachment to the respective literature entry in your Zotero group. This will enable other researchers in your group to see your notes, once you read the file and uploaded it to this place.
  3. Reading and annotating. All files you want to read will now appear in your Incoming.mm in Docear, because you added them to your Literature directory. Order them into your reading list in Literature & Annotations.mm. Click the links there to start reading, with PDFXChange as your PDF reader. Create annotations, bookmarks and text highlighting as desired in PDFXChange, and save. To simplify your later task of finishing your own articles, you should include in every bookmark, annotation and highlighted text the source, in brackets; for example "[Gantt2001, pp.21]".
  4. Mobile reading and annotating (optional). [TODO]
  5. Note organizing and drafting with Docear. 
    1. Click "Refresh" in your Docear's Incoming.mm to get your PDF bookmarks, notes and annotations into Docear.
    2. If you intend to create a thesis, you want to use a dedicated mindmap for its draft, else drafting multiple articles in one mindmap seems most comfortable.
    3. I like to create an "inbox" node in the mindmap and collect all my ideas into that whenever you don't have the time to find a more appropriate place for them.
    4. Create an initial table of contents as a hierarchical node structure in your article / thesis draft mindmap.
    5. Add, copy, move nodes and rework your table of contents hierarchy until the textual part of your thesis is done. For me that means, until the written thoughts form collections that I consider drafts for the article(s) I want to write. Finishing the wording and getting the sentences connected properly can be done more comfortably in LibreOffice.
    6. You can click the links of bookmark, annotation and highlighted text notes to look them up in their original document, which is in my view the greatest feature in Docear.
  6. Writing and publishing with WordPress.
    1. Sync to Zotero. That is, sync your Zotero literature database to the Zotero server; necessary because it will be accessed by your ZotPress and Enhanced-BibliPlug plugins.
    2. Copy and paste your article draft. You can just copy your complete list of draft notes into a WordPress post and start editing it from there.
    3. Finish your article. 
    4. Replace text refs with real literature references. You will of course lose the link information then, but as you added the literature refs before to the bookmarks, notes etc. (like "[Gantt2001, pp.21]"), this is not much of a problem. Just double-click to select a literature key of such a reference, copy it, then insert a corresponding literature reference with ZotPress by pasting the key in its dialog. [TODO: How can this be more automated? Selecting the text and using a key combination would be enough. Maybe possible by configuring the rich text editor for inserting a special tag that way, if ZotPress recodnizes literature references in text based on tags.]
    5. Insert links to fulltext files (optional). You can make the "p.xy" part of literature references a regular hyperlink to a PDF file, with a subpart marker to let it go to the page of bookmark conforming to the citation. And for faster own use that also shows your annotations etc., you can add the an analogous link afterwards, leading to the corresponding offline file on your own computer using a file://~/Data/Literature/key.authorname.pdf scheme. I would recommend to make the public link resolve directly to the original article on the web, if possible via a DOI resolver, and not to your annotated version, proving that you cite unchanged material. You might add a link to your public, annotated version afterwards. I like to use Unicode icon characters for these last two links for compactness. My proposals:
      • ⛁: "Squared Plus" (U+229E) for "annotated document" and "White Draughts King" (U+26C1) for "local hyperlink" because it looks like the missing hard disk symbol.
      • ⌂: "Strictly Equivalent To" (U+2263) for "annotated document" and "House" (U+2302) for "local hyperlink".
    6. Upload fulltext files (optional). Upload them into a directory of your own server; using Zotero server space is also possible, but can be quite expensive. Needed when you inserted links to individual pages etc. in them, see above. Also needed when you inserted links to them as files in your reference list, which can be needed when the work is not publicly accessible. You will have to password protect access to these links, but at least you can thus share these files with the researchers in your group.
  7. Writing and publishing with LibreOffice. The advantages over WordPress are more advanced formatting options in LibreOffice, and the option to create a high-quality PDF version from it without manual efforts. Which is both needed when writing for journals, but else, writing directly in WordPress seems like the simpler variant for writing about your research and publishing it on the web. Except of course you have no Internet access, then LibreOffice is best (even if you just use it in HTML mode, basically as a HTML editor for later copying into WordPress).
    1. Copy and paste your article draft. Just as when writing for WordPress. If it's a long and structured draft in Docear, like for a thesis, you better export it as follows, to get your table of contents structure over into LibreOffice as well:
      1. Unfold the mindmap so that all notes belonging to TOC headings are visible, but not more.
      2. Then export to .odt format in Docear. The visible nodes will become the headings there, and thus will be included into the TOC when you add a "Table of Contents" directory into your LibreOffice document.
      3. Open the .odt document in LibreOffice and transform the formatting from hard-coded to style-based. [TODO How can this be done efficiently?]
    2. Replace text refs with real literature references. Just as when writing for WordPress. [TODO: There has to be a feature to convert selected text into a literature reference.]
    3. Insert links to fulltext files (optional). Just as when writing for WordPress. But to link to local fulltext files, you can't use the "file://" URL scheme in LibreOffice, such links are automatically converted to "smb://". Instead, use relative paths to files, without any directory prefix. That's because you will view your article locally in PDF format after it's finished, and then it resides in your own "Literature" files directory, as your own publication alongside all those of others.
    4. Add a link to the PDF version. At the beginning of the document, create a link to the PDF version of it. As this PDF will be part of your regular literature database, just create an entry in Zotero for it and link to it with the same scheme you use for linking to online fulltext versions of cited works.
    5. Remove links to local fulltext files in a copy (optional). Links to local fulltext files are only relevant for yourself, so you might want to hide them in the version that is published on the web. Removing these links is simple, even though LibreOffice supports no links in conditional text: if you used symbols as link text, just search&replace them with nothing.
    6. Export to PDF. Be sure to check "Export links relative to the filesystem." in the PDF export options in LibreOffice. Place the PDF into your "Literature" directory.
    7. Upload fulltext files (optional). Just as when writing for WordPress. Includes uploading the PDF version of your own article.
    8. Publish in WordPress. Should be as simple as exporting from LibreOffice to HTML, copying the HTML into WordPress and (optionally) replacing the textural literature references with ZotPress references. This however means manual work whenever doing changes to the article, so probably you better leave that out.
  8. Viewing your web-published content. It is not ideal to use the Firefox integrated PDF viewer for viewing annotated PDFs; while it correctly understands subpart links (like #2 for "page two") and shows annotations and bookmarks, it does not show highlighted text. So better open links to annotated PDFs in Adobe Reader or PDF-XChange, except you know you're not interested in the highlightings this time.
  9. Cleaning the literature database. You might think from time to time that some document that you once included in the literature database is not worth storing any more. But if you cited it, you should. So there should be a command to determine if you cited a specific work, identified by its BibTex key (which is the same as its file basename). If not cited, delete the file and all references in Docear mindmaps.

Reasoning

My last thesis was written in OpenOffice.org (now LibreOffice), and the one feature I really missed there was a comfortable way of moving notes, snippets and other parts of text around. Because getting a thesis done is, for a good part, just that: ordering and integrating notes and snippets that you wrote whenever you had an idea or insight.

Since that thesis, I became a FreeMind enthusiast, using it for nearly all my personal information management. It's truly great in this "ordering notes" task because three aspects come together: it's speedy enough in displaying and dragging even large mindmaps; it provides good optical clues for quick visual navigation in a huge hierarchical content structure, making it mentally less strenuous to work with it (unlike scrolling text in OOo or using OOo outline mode); it provides great keyboard shortcuts for quick navigation and reordering of nodes in the hierarchy. So I looked for a mindmap-based tool for scientific writing, and the above is what I found.

My reasons for individual aspects of this solution:

  • Why Zotero. This is my current recommendation for a reference management tool for LibreOffice, see my evaluation of reference managers for LibreOffice. Of course you could try to use Docear with integrated JabRef reference manager for reference management, see the discussion of the alternative below for the reasons why Zotero is used here. In any way, you will want a separate reference manager rather than treating references as just another node that you organize with Docear. Becuase a mindmapping tool is rather poor with structured data, it's no all-understanding knowledge management system by itself. Also, collaborating on a common bibliography would be difficult with such an approach.
  • Knowledge, not just cited works. This is a knowledge management system; that's why the literature database contains everything you think is worth storing, and not just works you cite or have annotated or have even read.
  • Docear for note management, not reference management. Note that we don't use Docear for literature reference managemet at all, we don't export anything from Zotero to Docear (although that's possible). That's because so far, there is no way to insert text with inline references from Docear nodes into LibreOffice so that it will contain LibreOffice literature references, and also no way to copy or insert a complete node with a link to a literature work from Docear into LibreOffice so that it will appear there as literature reference. The only thing we could do is use JabRef and JabRef plugins for LibreOffice to manually select literature entries from the Docear bibliography and create LibreOffice literature references from them. But that can equally well be done with Zotero and its LibreOffice plugins, plus, Zotero has a more efficient way of collecting document metadata when browsing the web, which is why we avoid JabRef. So there's no meaning in having the literature database available in Docear at all: Docear is used for notes and drafting, while references are only needed when finishing an article. Of course it still has to be easy to detect to what work of literature a note or quotation in an article drafted in Docear belongs; but that is possible in our system, as the PDF file link will contain the literature key as its filename, a scheme that has been tried and tested in practice.
  • Why not Semantik? Looking for mindmapping software for scientific writing, I found Semantik, a tool developed with just this purpose in mind. However, I found its current (as of 2011-08) version in several aspects more limited than FreeMind, while I found Docear to be more powerful than Freemind, esp. because of the PDF annotation management.
  • Why no collaborative annotating? In a group of researchers it will have some benefits if all can annotate the same work of literature and at the same time, see the annotations of others in there. In our solution, there is one file per author with his / her annotations on the contained work of literature. By downloading others' annotated versions into your Literature directory, Docear will import these annotations as well, so that the set of all annotations from all authors is then available in Docear instead of in a single PDF. This is a much simpler system, as it avoids concurrent edits and sync conflicts when editing one file in parallel. No functionality and not much convenience is given away.
  • Why Chromium? Because some WordPress rich text editors, or at least some functions of them, are horribly slow on some systems in Firefox because of some JavaScript functions being slow there. If it does not affect you, you may as well use Firefox.
  • Why not CiteULike? Zotero was preferred above CiteULike because it is completely free software (though this is not a big issue, as CiteULike offers your literature data in various download formats for you).

Alternative Solution Proposal: Docear + JabRef + BibSonomy

There is an alternative solution without Zotero, thus saving one separate software and also integrating funcionality tighter. However, it misses the sophisticated metadata grabbing features of the Zotero browser plugin, and also the Zotero "scientific social bookmarking" online groups are much more and the service more well-known than newcomer BibSonomy (though they offer interesting features like a WordPress plugin). Still, some might rather want this solution. In this solution, you would use these tools:

  • BibSonomy website. For reference collecting in your team.
  • JabRef. The reference manager integrated into Docear.
  • JabRef standalone. Additionally to the Docear integration using it as a standalone reference manager, for some added options.
  • JabRef plugins for LibreOffice. To insert JabRef references into articles you write.
  • BibSonomy plugin for JabRef. To collaborate with your group via the BibSonomy "scientific social bookmarking" website as an alternative to Zotero online groups and CiteULike.
  • AcademicPress WordPress plugin. Together with an online copy of JabPress's BibTeX file if you want to write directly in WordPress
  • BibSonomy CSL plugin for WordPress. To show your complete group bibliography in WordPress

Statistical Design Meeting and Workshop in Strasbourg, 2013-03-25 to -26.

We worked quite intensively and at the same time, everybody seemed to enjoy it – that's how I like work to be 🙂 Thanks to everybody involved!

All images on this page licenced under CC BY-SA 3.0 Unported, or at your option, any later version.
Please attribute to "Matt" and this page's URL (that is, do not use my real name).

Sorry for the bad image quality. My real cam broke down and I did not get around yet to repair it …

Setting up WordPress for this

  1. Download the Shoestrap theme [source]:
    cd <DOCUMENT_ROOT>/wp-content/themes/;
    git clone git://github.com/aristath/shoestrap.git;
  2. Create two or more variants:
    1. mv shoestrap shoestrap-default;
      cp -a shoestrap-default shoestrap-special;
    2. Edit file style.css of both your template copies and edit the "Theme Name:" line, configuring a unique name for both.
    3. In the WordPress template list (http://example.com/wp-admin/themes.php), all your template copies should now appear separately with their respective names.
  3. Go to "Appearance -> Shoestrap" and configure it to your needs, incl. a licence key. (It will be used for all installed Shoestrap instances,)
  4. Use the WordPress theme customizer ("Appearance -> Themes -> (choose theme) -> Customize / Live Preview") to customize your theme instances to your needs, and activate the theme instance that you want to be the default. Make sure to choose the correct theme activation options in the additional screen: if you have already a navigation menu, don't let it generate another one.
  5. Install the jonradio Multiple Themes plugin.
  6. Disable the Shoestrap theme activation options screen. This is helpful to save click work, because to configure a non-default theme for jonradio Multiple Themes, you have to activate it shortly, then activate your default screen again ["method 1" in the plugin's FAQ]. To disable this, edit the file lib/activation.php in all your Shoestrap instances and replace line 7 with:
    # wp_redirect(admin_url('themes.php?page=theme_activation_options?page=theme_activation_options')); # Original.
    wp_redirect(admin_url('themes.php?page=theme_activation_options'));

Configuring your multiple themes

In "Appearance -> Themes" you see multiple themes, one for each of the blog's differently styled areas. How to configure them:

  • The activated theme can be configured in the regular WordPress Theme Customizer ("Appearance -> Themes -> (active theme) -> Customize" or the bottom-left blue triangle in the frontend site when you're logged in).
  • To add and configure different (copies of) a theme for different parts of your website, the "Multiple Themes" plugin is used. See "Appearance -> Multiple Themes plugin".
  • To configure the appearance of a theme that is not "activated" as the default but used on some subpart of the site, edit it with the Appearance -> Themes -> (some theme) -> Live Preview" feature, and after saving re-activate your default theme. Detailed explanations here (under "method 1").

If you want to edit even more aspects of the templates, you can do so on CSS level (including the use of LESS variables):

  1. You should install the WPide editor plugin and use it to edit the theme's CSS files, as they reside in subdirectories where they can't be edited with the integrated WordPress editor. Alternatively, if you have SSH access, use a console based editor like vi of course.
  2. First, choose "Enable Developer Mode" in "Appearance -> Shoestrap" and save that settings page.
  3. Then edit this file in the concerned Shoestrap theme: assets/less/app.less.
  4. After all edits are done, disable developer mode again.