Fryboyter

Manche Artikel werden nun mehrsprachig angeboten

In den letzten Jahren habe ich mir ab und zu überlegt, ob ich zumindest manche Artikel nicht zusätzlich auch auf Englisch veröffentliche. Bisher war mir allerdings die technische Umsetzung zu umständlich. Mit Hugo ist es allerdings schnell gemacht, wie ich heute festgestellt habe.

Als erstes erweitert man die Konfigurationsdatei config.toml um folgende Einträge.

DefaultContentLanguage = "de"

    [languages]
    [languages.de]
        languageName = "Deutsche Version"
        weight = 1
    [languages.en]
        languageName = "English version"
        weight = 2

Mit der ersten Zeile gibt man an, dass de die Standardsprache ist. Der Rest definiert die vorhandenen Sprachen, gibt Ihnen eine Bezeichnung und eine Gewichtung (umso niedriger umso wichtiger).

Nun erzeugt man einen neuen Artikel. Nennen wir die Datei einfach mal manche-artikel-nun-englisch.md. Nehmen wir nun einmal an, der Artikel ist wichtig genug, dass wir ihn nun auch auf Englisch veröffentlichen möchten. Also erzeugen wir einen weiteren Artikel und nennen die Datei manche-artikel-nun-englisch.en.md. Wie man sieht wurde der Titel um ein .en erweitert. Hugo kapiert nun automatisch, dass der Artikel mit .en die englische Version darstellt und die andere die deutsche Version.

Was aber, wenn nun jemand die deutschsprachige Version aufruft, aber kein Deutsch versteht? Hier müsste eine Art Umschalter vorhanden sein. Hierfür kann man zum Beispiel folgenden Code verwenden.

{{ if .IsTranslated }}
    {{ range .Translations }} | {{ .Language.LanguageName }} {{ end}}
{{ end }}

Hiermit wird geprüft, ob der Artikel auch in einer anderen Sprache angeboten wird. Wenn ja wird auf die entsprechenden Versionen verlinkt. Wenn nicht, wird gar nichts angezeigt. Diesen Code habe ich auf fryboyter.de unter die Hauptüberschrift aller Artikel gepackt. Sollte dort nun bei einem Artikel der Link “English version” erscheinen, habe ich mir die Arbeit gemacht und den Artikel auch auf Englisch veröffentlicht. Aktuell wird man diese Verlinkung aber nur bei diesem Artikel finden. Nach und nach werden es aber mehr Artikel werden die ich auf Deutsch und Englisch anbiete (auch ältere).

OSBN | Allgemein

Warum verhalten wir uns so?

Ich habe gerade ein paar Runden CS:GO Deathmatch hinter mir. In jeder Runde gab es mindestens einen Mitspieler der der Meinung war jemanden heftig beleidigen zu müssen. Was soll der Scheiß?

Heutzutage sehen es viele scheinbar für normal an, dass man sich in einem Multiplayer-Spiel Krebs wünscht, dass die eigenen Mutter von Mitspielern gefickt wird oder was auch immer. Es kotzt mich nur noch an. Spätestens jetzt kommt eigentlich immer jemand an, der mir erklärt, dass ich einfach eine dickere Haut brauche. Weil das ist doch normal. Nein, verdammt, das ist es nicht. Früher auf LAN-Partys und beispielsweise Q3A-Servern hat es auch ohne Beleidigungen funktioniert.

Was ich allerdings noch schlimmer finde ist, dass man sich auch in der OSS-Szene immer mehr ankackt. Du benutzt nicht vim? Noob!!! Du hast nicht Arch Linux installiert? Du hast doch keine Ahnung von Linux!!! Du nutzt eine Grafikkarte von Nvidia? Vollidiot!!!

Jesus fucking Christ!

Bei Linux bzw. OSS geht es doch auch um die freie Wahl. Zum Beispiel die Wahl eben nicht vim sondern Visual Studio Code, Sublime Text oder Micro zu nutzen. Und Befehle wie tar, cp, rsync usw. funktionieren unter OpenSuse genauso wie unter Arch Linux. Die Nutzung einer bestimmten Distribution verlängert daher nicht das primäre Geschlechtsorgan. Egal ob im virtuellen oder im echten Leben. Sorry wenn ich euch enttäuschen muss. Auch die Nutzung von Windows macht jemanden nicht zu einem schlechteren Menschen.

Was ist so schwer daran zu akzeptieren, dass jemand zum Beispiel einen anderen Editor nutzt als man selbst? Oder eine andere Versionverwaltung? Oder ein anderes Betriebssystem?

Bleiben wird mal bei OSS. Es ist doch scheißegal, ob jemand solch eine Software mit vim oder Visual Studio Code entwickelt. Es ist doch scheißegal ob er für die Versionsverwaltung Git oder Mercurial verwendet. Was zählt ist das Ergebnis. Und im Grunde ist auch das Ergebnis scheißegal, da man auch einfach mal akzeptieren muss, nicht teil der Zielgruppe zu sein.

Was aber nicht scheißegal ist, zumindest meiner Meinung nach, wie man mit anderen umgeht. Vor allem wenn sie im Grunde genommen ähnliche Ziele verfolgen. Von daher sollten wir uns vielleicht öfter an die eigene Nase fassen anstelle andere zu kritisieren.

Allgemein | OSBN

Hooks unter Mercurial

Gestern hatte ich ja bereits einen Artikel veröffentlicht, der die Versionsverwaltung Mercurial betrifft. Das betreffende Projekt wurde bisher mit Git verwaltet. Hierbei gab es auch einige Hooks. Hiermit lassen sich zum Beispiel automatisch Befehle ausführen wenn ein neuer Commit hochgeladen wurde. Hierfür verwendet man den Hook “post-receive” wie ich es vor kurzem in einem Beitrag beschrieben habe. Zu diesem hat Tux auch einen Kommentar abgegeben, dass dies zum Beispiel auch mit Mercurial möglich ist.

An sich absolut korrekt, aber entweder ist die Dokumentation verbesserungswürdig oder ich stand auf der Leitung. Ich gehe an der Stelle mal von letzterem aus.

Unter https://www.mercurial-scm.org/wiki/Hook wird das ganze beschrieben. Jedes mal wenn ich einen Commit einpflege, soll ein Hook ausgeführt werden. Also habe ich in der Konfigurationsdatei hgrc folgendes eintragen.

[hooks]
commit = /pfad/zur/Datei/commithook

Unter /pfad/zur/Datei/ habe ich dann die Datei commithook angelegt und dort eben das Script eingetragen, dass ausgeführt werden soll. Anschließend habe ich die Datei ausführbar gemacht.

Es hat aber nicht funktioniert. Die Commits sind zwar angekommen, der Hook wurde aber nicht ausgeführt. Nach etwas Google-Fu habe ich dann auch gemerkt wieso. Der Commit-Hook funktioniert scheinbar nur, wenn man den Commit direkt im Repository macht. Nicht jedoch wenn man diesen per push einträgt.

Man muss daher in die Datei hgrc folgendes eintragen.

[hooks]
changegroup = /pfad/zur/Datei/commithook

Damit wird der Hook dann auch immer bei einem Commit ausgeführt.

OSBN | Allgemein

Git zu Mercurial konvertieren

Oft kommt es vor, dass jemand von einer Versionsverwaltung zu Git wechselt. Ab und zu kommt es aber auch vor, dass jemand von Git auf eine andere Lösung wechseln will. Kürzlich hatte ich solch eine Anfrage. Gewünscht war Mercurial.

Das betreffende Git-Repository war noch recht frisch aber es gab bereits Commits im niedrigen dreistelligen Bereich. Zu viele um diese in Mercurial manuell anzulegen.

Was aber gar nicht nötig ist. Mercurial bietet die Möglichkeit der Konvertierung an.

Nehmen wir einmal an im Home-Verzeichnis gibt es das Verzeichnis repository. In diesem befindet sich das Verzeichnis blog.git in welchem das Git-Repository vorhanden ist.

Als erstes erzeugt man im Verzeichnis repository das Unterverzeichnis blog.hg und welchselt in dieses. Dort erzeugt man dann mittels “hg init” ein Mercurial-Repository. Hierbei wird das Verzeichnis .hg erstellt. In diesem erzeugt man die Datei hgrc mit folgendem Inhalt.

[extensions]
hgext.convert=

Hiermit aktiviert man die Erweiterung mit der man die Konvertierung vornehmen kann.

Nun führt man im Verzeichnis blog.hg folgenden Befehl aus.

hg convert --datesort ~/repository/blog.git ~/repository/blog.hg

Das ganze dauert dann etwas. Aber wenn alles geklappt hat, sollte man ein Mercurial-Repository mit allen Commits, Dateien usw. wie im Git-Repository erhalten. Sieht man sich das Verzeichnis blog.hg an, sieht man allerdings weiterhin nur das Unterverzeichnis .hg. Das Problem behebt man in dem man den Befehl “hg update” ausführt. Sieht man sich danach das Verzeichnis blog.hg an sieht man auch die ganzen Dateien die man ursprünglich zum Git-Repository hinzugefügt hat.

OSBN | Allgemein

Hugo updaten

Hugo ist auf meine Webspace nicht von Haus aus installiert. Daher muss ich neue Versionen manuell installieren. Um mir dies zu erleichtern habe ich mir ein kleines Script gebaut.

#!/bin/bash
BIN_DIR=$HOME/bin
CUR_VERSION="$("$BIN_DIR"/hugo version 2>/dev/null | cut -d'v' -f2 | cut -c 1-6)"
NEW_VERSION=$(curl --silent "https://api.github.com/repos/gohugoio/hugo/tags" | jq -r '.[0].name' | tr -d v)

echo "Hugo:  Aktuelle Version: $CUR_VERSION => Neue Version: $NEW_VERSION"

if ! [ "$NEW_VERSION" = "$CUR_VERSION" ]; then

  curl -L --output hugo.tar.gz "https://github.com/gohugoio/hugo/releases/download/v${NEW_VERSION}/hugo_${NEW_VERSION}_Linux-64bit.tar.gz"
  tar -C "${BIN_DIR}" -xvzf hugo.tar.gz hugo
  rm hugo.tar.gz
else
    echo "Die aktuelle Version von Hugo ist bereits installiert"
fi

Hiermit wird geprüft, ob die aktuelle Version die auf Github angeboten wird, aktueller ist als die, die auf dem Webspace vorhanden ist. Wenn ja, wird die aktuelle Version von Github heruntergeladen und auf dem Webspace gespeichert.

OSBN | Allgemein