Commons talk:LrMediaWiki/archive 2021

New release: 1.0.2

Today a new version has been released: v1.0.2 (direct download link)

Implemented issues are:

• https://github.com/robinkrahl/LrMediaWiki/issues/97 – Language (other) must be set for each item (enhancement)
• https://github.com/robinkrahl/LrMediaWiki/issues/100 – Exception handling if a variable is empty missing (enhancement)
• https://github.com/Hasenlaeufer/LrMediaWiki/issues/8 – MetaWikiMetadataSetAll.lua has no com.adobe.title (bug fix)
• https://github.com/Hasenlaeufer/LrMediaWiki/issues/12 – Feature: Update only (enhancement)
• https://github.com/Hasenlaeufer/LrMediaWiki/issues/13 – Do not fill location template if "Remove Location Info" is checked (enhancement)
• https://github.com/Hasenlaeufer/LrMediaWiki/issues/22 – Current date as placeholder (enhancement)

Version 1.0 missed an update of the file CHANGELOG.md with the mentioned changes, version 1.0.1 includes an updated CHANGELOG.md. Version 1.0.2 updated Info.lua.

Hasenläufer 10:05, 10 January 2021 (UTC)

Thanks a lot, works with LR 6.14 Win. Raymond 10:28, 11 January 2021 (UTC)

Thanks for the feedback. I mainly tested with LR 5.7.1 Mac and didn't spend much time with newer LR versions and Win. Hasenläufer 21:08, 11 January 2021 (UTC)

Have extracted and installed. Seems to run on Lightroom Classic 10.1 Windows 10. But have not put it to regular test yet.

Why does the extracted folder not have an extension name? 4.0. 5.0, 8.0? It is just renamed LrMediaWiki.lrplugin instead of mediawiki.lrplugin 8.0. Is there a reason why the information is only just here and not yet up front?

It's "up front". See Plug-in Manager.../Zusatzmodul-Manager... → LrMediaWiki → Status → Version --Hasenläufer 21:08, 11 January 2021 (UTC)

But appart from this little nagging, thanks for keeping the work on the plugin running. This pluggin was my reason to change my workflow to Lightroom and I haven't regretted it. --Wuselig (talk) 13:14, 11 January 2021 (UTC)

Ich habe das Plugin aktualisiert, vielen Dank dafür. Neu ist das beim Export die Positionsdaten leider nicht mitgeschickt werden. Das Problem mit der Fehlermeldung beim zweiten upload hat sich nicht gebessert.--Ermell (talk) 15:59, 12 January 2021 (UTC)

Hallo Hasenläufer, das Problem mit den Koordinaten kann ich bestätigen: Beim Upload heute Morgen (siehe z. B. File:2021-01-10 Handball, EHF European League Women, Thüringer HC - Astrakhanochka 1DX 4305 by Stepro.jpg) fehlen sie plötzlich, ohne eine Änderung auf meiner Seite - von der Aktualisierung des Plugins natürlich abgesehen. --Stepro (talk) 16:44, 12 January 2021 (UTC)

Das Thema Positionsdaten bzw. Koordinaten bezieht sich auf die Vorlage {{Location}}, siehe https://github.com/Hasenlaeufer/LrMediaWiki/issues/13 – Dort ist beschrieben, wie man das Generieren die Vorlage ein- und ausschalten kann. Ein Feature, kein Bug. Hasenläufer 17:28, 12 January 2021 (UTC)

Sorry, aber wenn etwas bisher funktionierte, und nun nicht mehr wie bisher funktioniert, dann ist das ohne deutliche Info für mich kein Feature. Und Deine Antwort fand ich jetzt auch nur begrenzt hilfreich.

Für alle: Wenn man weiter wie bisher die Koordinaten mit nach Commons übertragen möchte, muss man im "Lightroom-Zusatzmodul-Manager" im entsprechenden Plugin "LrMediaWiki" den Punkt {{Location}}-Vorlage aktivieren anhaken. --Stepro (talk) 18:19, 12 January 2021 (UTC)

Der neue Schalter hat offenbar einen Standardwert von "Aus". Er sollte standardmäßig auf "Ein" stehen. Sorry, das hatte ich übersehen. Das ist ein Bug. Wird gefixt. Danke für den Hinweis! Hasenläufer 18:42, 12 January 2021 (UTC)

Das ist natürlich eine Erklärung. ;-) --Stepro (talk) 19:35, 12 January 2021 (UTC)

New release: 1.1

A new version has been released: v1.1 (direct download link)

Implemented issues are:

1. https://github.com/Hasenlaeufer/LrMediaWiki/issues/26 – Location template default should be "On" (bug fix)
2. https://github.com/robinkrahl/LrMediaWiki/issues/99 – Remove duplicate categories (enhancement)
3. https://github.com/robinkrahl/LrMediaWiki/issues/45 – Keyword-based categories (enhancement)

• [1] is a fix of release 1.0.2. The default value of {{Location}} usage is set from "Off" to "On".
• [2] removes duplicates of categories. This is a silent process without any user information or interaction.

[3] is a theme which might need to be discussed. It's a proposal. The idea is to use special marked keywords as category names. If a keyword has a preceeding hash sign # it's interpreted to be a category name. To give an example: If we have the keyword "#John Doe" the term "John Doe" is interpreted as a category name; the result is [[Category:John Doe]]. As a result we have three opportunities to add categories:

• per file, field "Categories", separator of multiple categories is a semicolon
• per export, field "Categories", separator is a semicolon
• per category, syntax like a hashtag, separator is a comma

Advantages of keyword-based catgories by this proposal:

• LR provides a mighty system to manage keywords: keyword tags, keyword suggestions, keyword sets, keyword list, ... – All these features can be used to manage often used categories.
• Easy to implement and to maintain. No need to implement an editor to edit relationships between keywords and categories. BTW, this seems to be impossible, because the SDK provides no UI elements like a dynamic list.

Disadvantages:

• The two different separators semicolon and comma might confuse
• @Toresetre: You mentioned at the issue tracker four years ago, it might lead to performance issues. Any news related to this theme?
• The semantic of keywords and categories is mixed inside the keyword system: "#John Doe" and "John Doe" have different meanings. Is this a problem?
• The category keywords (hashtags) might disturb workflows outside Wikimedia Commons – any workflow including keywords. Is this a problem?

Please feel free to give feeedback and to participate in a discussion. I'm in doubt if this concept is a good idea or not. Is it a great thing or stupid stuff? Hasenläufer 23:50, 12 January 2021 (UTC)

Hallo Hasenläufer, vielen Dank für Deine Ideen und Umsetzungen. Ich weiß natürlich nicht, wie andere das nutzen, aber ich beschreibe mal, warum ich die meisten Kategorien erst nach dem Upload direkt auf Commons (mühsam) hinzufüge, statt sie gleich in LR einzutragen. Dabei ist vielleicht wichtig zu wissen, dass es bei mir fast immer um Personenkategorien geht.

Zum einen ist da natürlich die Autovervollständigung. Ich müsste nahezu immer erst auf Commons nachsehen, wie die betreffende Kategorie dort heißt und vor allem genau geschrieben ist (mal in Originalsprache, mal in englischer Transkription, mal mit und mal ohne diakritische Zeichen, mal mit und mal ohne zweitem Vornamen usw.), sie kopieren, und in LR einfügen. Das geht dann leider schneller, wenn ich nach dem Upload auf Commons jedes Foto einzeln öffne, und die betreffenden Kategorien per HotCat einfüge. Trotzdem ist das bei meist mehreren hundert Fotos (und manchmal auch mehr als tausend Fotos) extrem zeitraubend und mühselig.

Das andere Problem ist die Trennung per Semikolon im Feld der Metadaten. Genauer beschrieben: Die Bildunterschrift enthält bei mir faktisch immer die Namen der abgebildeten Personen. Daher wäre es eigentlich ein leichtes, nach einzelnen Namen zu filtern, alle betreffenden Fotos zu markieren, und dann die richtige Kategorie in das Feld der Metadaten einzufügen. Nur funktioniert das leider nicht mehr, wenn mehrere Personen auf den Fotos sind - was ja recht häufig vorkommt. Denn dann würden die bereits vorhandenen Kategorienamen schlicht überschrieben werden. Also würde dann, wenn die Kategorie von Person 1 schon im Feld steht, diese mit der Kategorie von Person 2 überschrieben werden. Ich habe leider keine Idee, wie man dieses Problem lösen könnte.

Nun könnte Deine Umsetzung mit dem Stichwort vielleicht eine Lösung sein. Was für mich aktuell noch dagegen spricht: Ich müsste für tausende Menschen Stichwörter anlegen. Natürlich macht man so etwas nach und nach, und man kann sie ja (in meinem Fall) nach Sportarten o. ä. gruppieren, um nicht völlig die Übersicht zu verlieren, aber es ist trotzdem recht umständlich. Und ein anderer Punkt: Beim Upload zu Commons filtert das Plugin zwar das # vor dem Namen raus, so dass es ordentlich funktioniert, aber bei allen anderen Uploads oder Exports (auch auf die Festplatte) wäre immer ein Stichwort mit im besten Fall #Vorname Nachname enthalten, oft aber auch komische Namen wie sie die Commonskategorien nun einmal haben. Aber selbst mit "normalen" Namen z. B. #Markéta Jeřábková würde man alle anderen Plattformen verwirren - schon allein durch die vielen Nicht-Ascii-Zeichen. Das wäre dann wohl Dein 4. Punkt unter "Disadvantages".

Wie gesagt: Ich habe leider keine Idee, wie man mein Dilemma hier lösen könnte. Und ich weiß auch nicht, ob ich damit eher ziemlich allein bin, oder ob andere auch dieses Problem haben. Ich wollte es aber mal genauer beschreiben, damit Du (und andere) wissen, woran es haken könnte. --Stepro (talk) 02:04, 13 January 2021 (UTC)

Da die Kategorisierungsstruktur ins Speziellste geht, meine Stichwortstruktur in Lightroom aber meinen Suchkriterien entspricht, entfallen übergeordnete Stichworte bei der Kategorisierung. Ich nutze Lightroom auch weil es mir bei der Kategorisierung und Beschriftung hilft. Weil ich durch das Zusammenfassen von Bildern die Beschriftung vom Allgemeinen zum Speziellen immer mehr einengen kann. Dieses Bild hat die Stichworte "August Macke", "LWL-Moderne", "LWL-Museum für Kunst und Kultur", "Münster", "Sony-Alpha 6000 ILCE-6000", "Walimex 12mm F2.0". Zwei davon haben es als versteckte Kategorien geschafft, aber die offizielle Kategorie ist "Sonniger Weg (1913) by August Macke". Ich könnte mir aber vorstellen, dass die Übernahme der Stichworte für "Structured Data" eine weitere Überlegung wert wäre. Deshalb werde ich es mal mit eben diesen zwei Kategorien bei zukünftigen Uploads mal ausprobieren. Als zusätzliches Feature beginne ich bei nochmaligem Durchlesen einen Sinn zu erkennen.

Danke übrigens zum Hinweis mit der Georeferenzierung. Ist mir zunächst nicht aufgefallen. --Wuselig (talk) 11:17, 13 January 2021 (UTC) mit Ergänzung --Wuselig (talk) 11:26, 13 January 2021 (UTC)

Ich habe das mit den Hashtags jetzt einmal ausprobiert: File:Staatsgalerie Neuburg-Fyt-Reiher von Falken verfolgt DSC6320.jpg. In meiner Stichwortsortierung befindet sich das Bild in "Staatsgalerie Neuburg" in einem Unterstichwort "Flemish paintings in the Staatsgalerie Neuburg". Nach Commonsstandards sollte nur die letzte Kategorie gesetzt sein. Wenn ich jetzt noch für zukünftige Uploads die Kategorie "Paintings by Peter Paul Rubens (Staatsgalerie Neuburg)" anlege und die Bilder von Rubens als Unterstichwort der "Flemish painting..." einordne, dann werden alle drei Kategorien gesetzt. Ich habe übrigens bewusst das Häckchen beim übergeordneten Stichwort entfernt. --Wuselig (talk) 08:23, 14 January 2021 (UTC)

Learning by doing: In "Stichwort bearbeiten" darf der Haken bei "Übergeordnete Stichwörter exportieren" nicht gesetzt sein, dann funktioniert es wie gewünscht. Aber jetzt eine weitere Frage: Was sind Synonyme, die ebenfalls exportiert werden können? --Wuselig (talk) 13:08, 14 January 2021 (UTC)

Das ist so ziemlich das, wonach es klingt. ;-) Konkretes Beispiel: Wenn ich bei mir das Stichwort "Fußball" anklicke, werden automatisch auch die Stichwörter Calcio, Fotball, Fussball, Futbol, Le Football, soccer und Voetbal hinzugefügt. Klicke ich "Weltmeisterschaft" an, wird automagisch auch "World Championship" hinzugefügt. --Stepro (talk) 20:50, 14 January 2021 (UTC)

Danke! Sind das Synonyme aus Deinem Stichwortverzeichnis und stehen sie dort an unterschiedlichen Orten, z.B. als Unterstichwort zu einem Veranstaltungsort, oder muss eine engere Beziehung bestehen? Mit hinzufügen meinst Du in den Exifs, oder hast Du schon mit den Hashtags experimentiert? --Wuselig (talk) 07:16, 15 January 2021 (UTC)

Das Stichwort heißt "Fußball" (und ist ein Unterstichwort von "Sport", aber das spielt eigentlich keine Rolle), und die anderen Begriffe stehen mit Komma getrennt im Feld "Synonyme". Dabei ist "Synonyme exportieren" angehakt.

Unterhalb von "Fußball" habe ich weitere Stichwörter, die ich bei Bedarf auch noch auswähle, z. B. "UEFA Women's Champions League" oder "Flyeralarm Frauen-Bundesliga".

Ja, die landen in den EXIF- bzw. IPTC-Feldern und werden von Fotodatenbanken wie Imago oder dpa automatisch ausgelesen und als Schlagworte in deren Datenbanken hinzugefügt. Deswegen sind für mich die korrekten Stichwörter auch wichtig, und da darf nichts "komisches" dabeistehen, was nur das Commons-Plugin versteht. --Stepro (talk) 18:15, 15 January 2021 (UTC)

Okay, die Synonyme sind von Dir vorgegeben, spielen aber für unser LrMediaWiki Add-on keine Rolle. Problematisch bleibt für Dich, dass Deine Stichworte, die eben auch für andere Nachnutzer wichtig sind, nicht durch das Anhängen von Hashtags unhandlich, oder schwerer lesbar werden. Ich kann Dir folgen, aber - on second thought - frage ich mich, wie sich dies zum Beispiel von Instagram, und ähnlichen Plattformen unterscheidet? Hashtags haben sich dort ja auch etabliert. Würden Deine Nachnutzer das wirklich nicht mehr lesen und nutzen können? Andererseits, Frage an die Entwickler, ließen sich die Hashtags beim Export an andere Medien möglicherweise von der Software unterdrücken? --Wuselig (talk) 08:33, 16 January 2021 (UTC)

Zur „Frage an die Entwickler, ließen sich die Hashtags beim Export an andere Medien möglicherweise von der Software unterdrücken?“:

Ja, das geht. Neuerdings mit v1.1.1. Es war eine kleine Source-Code-Änderung erforderlich. Die "Hashtag"-Stichwörter sollten als privat markiert sein: Dann werden sie nicht exportiert, aber das Generieren der Kategorien klappt nach wie vor. Gruß, --Hasenläufer 15:16, 16 January 2021 (UTC)

New release: 1.1.1

A new version has been released: v1.1.1 (direct download link)

Implemented issues are:

• https://github.com/Hasenlaeufer/LrMediaWiki/issues/27 – As private marked hashtag keywords should be used as categories (enhancement)

Keywords can be marked as "private". This means, they will not get exported. However, "hashtag" keywords are used as Commons categories. To mark a ("hashtag") keyword as private:

• English: Keyword List → Double click a ("hashtag") keyword → Switch off "Include on Export"
• German: Stichwortliste → Doppelklick auf ein ("Hashtag"-)Stichwort → "Ebenfalls exportieren" ausschalten

To verify go to

• English: Keywording → Keyword Tags → "Keywords & Containing Keywords" vs. "Will Export"

As usual, use "Export" and "Preview of generated Wikitext".

• German: Stichwörter festlegen → Stichwort-Tags "Stichwörter & Enthält Stichwörter" vs. "Wird exportiert"

Wie üblich, benutze "Exportieren" und "Vorschau des generierten Wikitextes".

Hasenläufer 15:09, 16 January 2021 (UTC)

Nochmal {{Location}}

@ Hallo Hasenläufer,
erstmal vielen Dank für dieses Tool das für meine Arbeit bei Wikimedia Commons sehr hilfreich ist.
Offensichtlich habe ich das Feature mit der {{Location}}-Vorlage nicht verstanden.
Bei mir lässt sich die Checkbox "{{Location}}-Vorlage aktivieren" unter Lightroom-Zusatzmodul-Manager > LrMediaWiki > LrMediaWiki-Einstellungen nicht dauerhaft deaktivieren.
Wenn man die Checkbox deaktiviert, dann wird trotzdem das {{Location}}-Template angelegt was manchmal nicht gewünscht ist. Beim erneuten Aufruf des Zusatzmodul-Managers ist die Checkbox wieder aktiviert.
-- F. Riedelio • Diskussion • ✉ 19:04, 16 January 2021 (UTC)

Ups. Mir ist da ein Fehler unterlaufen. Danke für Deine Aufmerksamkeit! Ich werde wohl eine Version 1.1.2 mit einer Fehlerbehebung erstellen müssen. Sorry. Hasenläufer 14:02, 17 January 2021 (UTC)

New release: 1.1.2

A new version has been released: v1.1.2 (direct download link)

Implemented issues are:

1. https://github.com/Hasenlaeufer/LrMediaWiki/issues/26 – Location template default should be "On" (bug fix)

The bux fix by v1.1 is buggy. This is a fix of this fix. Sorry for the inconvenience. Hasenläufer 15:08, 17 January 2021 (UTC)

Feld "Andere Sprache"

Hallo Hasenläufer, sowohl in der Version 1.0.2 als auch der heute installierten Version 1.1.1 fehlt das Feld "Sprache (andere)". Bisher befand sich das Feld direkt unter "Beschreibung (andere...)". Übersehe ich etwas? Raymond 12:35, 17 January 2021 (UTC)

Mit Version 1.0.2 ist das Feld in den Export-Dialog verschoben worden. Dort ist es persistent. Siehe https://github.com/robinkrahl/LrMediaWiki/issues/97 Gruß, Hasenläufer 13:58, 17 January 2021 (UTC)

Ah danke, da hatte ich nicht gesucht. Mein Anwendungsfall des Feldes ist eher sporadischer, variantenreicher, abhängig vom Land bzw. dessen Sprache, indem ich Fotos gemacht habe. Aber ok, ich kann mit der Lösung leben, da ich nicht dauernd zwischen weiteren Sprachen hin- und herschalte. Raymond 17:48, 17 January 2021 (UTC)

Ich verstehe Dich noch nicht ganz. Fehlt Dir irgend etwas? Hasenläufer 17:55, 17 January 2021 (UTC)

Konkret: Mir fehlt das Feld auf der rechten Seite der Metadaten. Weil ich immer mal wieder andere Sprachen habe. Bin ich in Frankreich, möchte ich den Namen der Kirche in Französisch eingeben (neben Deutsche und Englisch). Bin ich ich in den Niederlanden, möchte ich den Namen des Objektes in niederländisch angeben. Usw. Ich persönlich bräuchte mehr Flexibiltät, weniger Persistenz, in der anderen Sprache. Da ich aber nicht laufend die Sprache wechsel, kann ich auch mit der aktuellen Lösung leben. Raymond 07:32, 20 January 2021 (UTC)

So wie ich das aktuell verstehe, ist die Sprachauswahl im Exportdialog überflüssig, es reicht jetzt die Beschreibung(en) als komplett Template einzutragen. Das ist auf jeden Fall besser, als die Sprache beim Export auszuwählen. Allerdings kommt beim Export bei jedem Bild die Warnung, das die Sprachauswahl fehlt. Careerfromhome (talk) 19:58, 4 February 2021 (UTC)

Ich finde diese Warnung Das Feld "Beschreibung (andere)" ist gefüllt, aber "Sprache (andere)" ist nicht gesetzt. auch nervig, da ich meine Bildbeschreibungen in diesem Feld mehrsprachig erstelle und dazu die Vorlage LangSwitch verwende (Beispiel).

{{LangSwitch

 | en = Text

 | es = Texto

 | it = Testo

 | ca = Text

}}

Falls es für dieses “Problem” eine andere Lösung gibt, wäre ich für Hinweise dankbar.

-- F. Riedelio • Diskussion • ✉ 08:59, 16 February 2021 (UTC)

Diese „nervige“ Warnung war ein Benutzerwunsch. Ich verstehe, dass sie nervt. Im nächsten Release 1.2.1 wird sie wieder entfernt. --Hasenläufer 22:47, 20 February 2021 (UTC)

New release: 1.2

A new version has been released: v1.2 (direct download link)

Implemented issues are:

• https://github.com/Hasenlaeufer/LrMediaWiki/issues/9 – Support for File captions (enhancement)

English: This release introduces a new additional field at metadata panel: "Caption (en)". The value will be shown on the file description page at section "File information → Captions".
This is a first step supporting "Structured data". No further steps in this regard or new LrMediaWiki features are currently planned.

Deutsch: Dieses Release führt ein neues zusätzliches Feld im Metadaten-Panel ein: "Kurzbeschreibung (en)". Der Wert wird auf der Dateibeschreibungs-Seite dargestellt im Abschnitt „Dateiinformationen → Kurzbeschreibungen“.
Dies ist ein erster Schritt in die Unterstützung „Strukturierter Daten“. Aktuell sind keine weiteren Schritte in dieser Hinsicht oder neue LrMediaWiki-Features geplant.

Hasenläufer 00:00, 20 January 2021 (UTC)

Ich hatte das geleert, nachdem ich erst mal Gewohnheitsmäßig das Feld gefüllt hatte. Das Ergebnis war https://commons.wikimedia.org/w/index.php?title=File:Alter_Bergbau_Geroldsgr%C3%BCn_(MGK31279).jpg&diff=prev&oldid=530022195 Ich kann dazu nichts erkennen, aber die 127 Bytes müssen ja irgendwo hingekommen sein. Careerfromhome (talk) 06:57, 4 February 2021 (UTC)

@Careerfromhome: Ich verstehe Dich nicht. War das Feld "Kurzbeschreibung (en)" gefüllt oder nicht? Wo ist ein Fehler? Welche 127 Bytes? --Hasenläufer 13:18, 21 February 2021 (UTC)

Es ist egal, ob das Feld gefüllt und dann geleert wurde, oder ob es Leer gelassen wurde. Es wird immer ein Edit mit +127bytes generiert.

21:03, 4. Feb. 2021 Unterschied Versionen  +127‎  File:Ban Khu Duea (MGK21675).jpg ‎ ‎Kurzbeschreibung [en] hinzugefügt: 0:)

Ich kann aber keine abgelegten Daten finden. Careerfromhome (talk) 14:27, 21 February 2021 (UTC)

Das „Mini-Feature“ funktioniert nur beim erstmaligen Anlegen einer Datei. LrMediaWiki editiert keine Metadaten einer bestehenden Datei. Liegt darin das Missverständnis? --Hasenläufer 17:01, 21 February 2021 (UTC)

Es handelt sich um neu hochgeladene Dateien auf die immer dieser ominöse Edit folgt. Careerfromhome (talk) 20:19, 21 February 2021 (UTC)

Jetzt erst verstehe ich, was Du meinst. Offenbar hast Du das neue Feld "Kurzbeschreibung (en)" leer gelassen. Daher wirkt die Bearbeitung ominös. Fülle das Feld, dann wird die Sache ersichtlicher.

Zum Hintergrund: Zunächst erfolgt ein Upload wie bisher. Dem folgt eine zweite Bearbeitung, in der das Feld "Kurzbeschreibung (en)" benutzt wird, um daraus einen Eintrag bzgl. Strukturierter Daten zu erzeugen. Es sind zwei aufeinanderfolgende API-Aufrufe unterschiedlichen Charakters, die sich durch zwei aufeinanderfolgende Bearbeitungen (Edits) in der Historie darstellen. Ich hatte erwähnt, dass dies ein erster Schritt in die Unterstützung „Strukturierter Daten“ ist. Das Thema ist Neuland für mich und die Anforderung ist etwas unzureichend formuliert: https://github.com/Hasenlaeufer/LrMediaWiki/issues/9 – Es wird in jedem Fall eine solcher Eintrag generiert, auch, wenn das Feld "Kurzbeschreibung (en)" leer ist. Das kann man natürlich ändern, so dass der 2. Edit nur erfolgt, falls "Kurzbeschreibung (en)" gefüllt ist. Das wird in der Anforderung nicht erwähnt.

Vielleicht habe ich die Anforderung falsch verstanden und irgendjemand, der mit dem Thema Strukturierte Daten besser vertraut ist, kann mir sagen, ob ich in der richtigen Richtung unterwegs bin oder nicht.

Meine Bemerkung "Aktuell sind keine weiteren Schritte in dieser Hinsicht oder neue LrMediaWiki-Features geplant." ist so zu verstehen, dass es aus meiner Sicht noch eine ganze Reihe ungeklärter Fragen beim Thema Strukturierte Daten gibt. Ich bin mir derzeit unsicher, ob ich mich in dieser Richtung weiter engagiere, denn eigentlich will ich mich aus dem Thema LrMediaWiki zurückziehen. Hasenläufer 21:42, 21 February 2021 (UTC)

Meine Ahnung von diesen Strukturierten Daten ist wahrscheinlich geringer als deine, deshalb meine Befürchtung das dieser 0 Edit mehr Schaden anrichtet als Nutzen (zB das es verhindert/verzögert, dass jemand mit Ahnung das Feld befüllt). Deshalb denke ich, dass ein ignorieren bei Leer angesagt ist. Zum Thema aus dem Thema LrMediaWiki zurückziehen: Meinst du du kannst ein paar Einweisungen per Zoom oder so machen, wie man die Entwicklungsumgebung aufsetzt, aus dem Code das Plugin schnürt und ein paar Grundsätzliche Fußangeln erklären. Das schlimmste ist der Einstieg. Der Code schaut eigentlich interessant aus. Careerfromhome (talk) 07:25, 22 February 2021 (UTC)

> Meine Ahnung von diesen Strukturierten Daten ist wahrscheinlich geringer als deine, ...

Geht schwerlich. Meine Ahnung ist knapp über Null.

„Ignorieren bei Leer“ findet auch meine Zustimmung. Vielleicht gibt es noch eine Wortmeldung, die für die aktuelle Variante plädiert. Daher sollten wir noch etwas abwarten.

> Meinst du du kannst ein paar Einweisungen ...

Na klar! Du (und jeder andere) ist herzlich willkommen und ich würde mein Bestes tun, um die Einstiegs-Schwelle abzusenken. Nur Mut! Hasenläufer 21:41, 22 February 2021 (UTC)

Zum Thema „Ignorieren bei Leer“ habe ich ein Issue erstellt. Wird im nächsten Release 1.3 gefixt sein. Hasenläufer 14:23, 27 February 2021 (UTC)

HTML-Elemente

@ Hallo Hasenläufer,
Ich verwende die HTML-Elemente (unary tags) <br> und <hr> um den Text in der Beschreibung zu strukturieren. Die Bildbeschreibung gebe ich in Lightroom in das Eingabefeld “Beschreibung (andere)” im allgemeinen Abschnitt ein.
Beispiel 1: Mit Tags, Ohne Tags, Beispiel 2: Mit Tags, Ohne Tags

Beim Export erhalte ich die Fehlermeldung "Der Platzhalter <br> wurde nicht ersetzt." und die Datei wird nicht nach Commons hochgeladen. Wenn ich die Tags entferne, dann lassen sich die Fotos hochladen. Allerdings muss ich diese dann im Commons wieder aufwändig und zeitraubend einfügen.
Gibt es vielleicht eine andere (bessere) Möglichkeit gewollte Zeilenumbrüche einzufügen?
Gruß, -- F. Riedelio • Diskussion • ✉ 18:56, 15 February 2021 (UTC)

@F. Riedelio: Das ist ein Bug. Danke für die Info! Ich kümmere mich darum. Gruß, --Hasenläufer 20:57, 20 February 2021 (UTC)

Wird in Version 1.2.1 gefixt sein. --Hasenläufer 22:50, 20 February 2021 (UTC)

Danke -- F. Riedelio • Diskussion • ✉ 18:45, 21 February 2021 (UTC)

New release: 1.2.1

A new version has been released: v1.2.1 (direct download link)

Implemented issues are:

• https://github.com/Hasenlaeufer/LrMediaWiki/issues/31 – HTML tags <br> und <hr> are no placeholders (bug fix)
• https://github.com/Hasenlaeufer/LrMediaWiki/issues/33 – Remove warning "The field “Description (other)” is filled, but “Language (other)” is not set." (enhancement)

For both topics see previous discussions. Hasenläufer 20:33, 21 February 2021 (UTC)

Seit v1.2.1: permissiondenied

Hallo Hasenläufer, seit heute, nachdem Update auf v1.2.1, erhalten ich nach jedem Uplaod den Fehler

Plug-in error log for plug-in at: D:\Lightroom\LrMediaWiki-master\LrMediaWiki.lrplugin

**** Error 1

Die Nachbearbeitungsaufgabe dieses Zusatzmoduls konnte nicht erfolgreich abgeschlossen werden.
The MediaWiki error permissiondenied occured: You do not have the permissions needed to carry out this action.

Das Hochladen selber funktioniert, siehe z.B. von heute File:Neubau Rheinbrücke Leverkusen im Baustopp Februar 2021 - Fundamente der linksrheinischen Vorlandbrücke-8669.jpg. Allerdings geht ein Batch-Upload nicht mehr, da nach der 1. Datei mit o.g. Fehler abgebrochen wird. Hast du eine Idee, was das sein könnte? Raymond 10:13, 22 February 2021 (UTC)

Ich habe die Antwort nun doch schnell gefunden: Da ich als Oversighter die Zwei-Faktor-Authenfizierung nutzen muss, nutze ich für das Plugin die Bot-Passwort-Funktion. Diesem Pseudo-Account musste ich die Berechtigung "Edit existing pages" erteilen, damit die nun erfolgende Bearbeitung für die strukturierten Daten durchgeführt werden darf. Die umseitige Doku werde ich nachher noch ergänzen. Raymond 10:23, 22 February 2021 (UTC)

Gut, dass Du die Antwort gefunden hast. Ich wäre vermutlich nie darauf gekommen!

> Die umseitige Doku werde ich nachher noch ergänzen.

Großartig, danke! Hasenläufer 21:26, 22 February 2021 (UTC)

@Raymond: Bei dieser Gelegenheit: Hast Du eine Meinung zu diesem Issue? Ich bin mir unsicher, wie ich damit umgehen sollte, da ich das Thema Zwei-Faktor-Authentifizierung bislang nur mit spitzen Fingern angegangen bin und extrem unsicher bin, ob die genannte Anforderung umgesetzt werden sollte. Es klingt nach viel Aufwand mit wenig Nutzen. Bei diesem Mini-Projekt haben wir kein Anforderungs-Management. Daher halte ich die Füße still, bis zumindest ein Zweiter schreit. Ein zweiter Schrei war bislang nicht zu hören. Daher wäre es hilfreich, von einem Kenner der Zwei-Faktor-Authentifizierung wie Dir zu hören, ob das gewünschte Feature notwendig ist oder nicht. Hasenläufer 23:33, 22 February 2021 (UTC)

@Hasenläufer: Den Aufwand kann ich nicht abschätzen, könnte mir aber vorstellen, dass die Integration eines Abfragefeldes für das 2FA-Token bei jeder Anmeldung auf Wikimedia Commons in LightRoom ein Problem sein könnte. Natürlich könnte auch mein Bot-Passwort-Account gehackt werden. Umseitig habe ich in der Doku vorgeschlagen, dass man den Bot-Passwort-Account "LrMediaWiki" nennen sollte. Das ist aber nicht zwingend. Das Hacken eines your-username@LrMediaWiki ist dann so einfach oder schwer wie das Hacken eines Standard-Accounts. Mit einem gehackten Bot-Passwort-Account kann aber nur soviel Unfug angestellt werden, wie ich Freigaben dafür erteilt habe, wie umseitig vorgeschlagen nur "Edit existing pages", "Create, edit, and move pages", "Upload new files", and "Upload, replace, and move files". Damit das Raten des Pseudoaccounts your-username@LrMediaWiki schwerer wird, würde ich vielleicht umseitig in der Doku dazu raten, einen Zufallsnamen zu wählen? your-username@your-private-bot-password-name? Raymond 07:40, 23 February 2021 (UTC)

New release: 1.3

A new version has been released: v1.3 (direct download link)

Implemented issues are:

• https://github.com/Hasenlaeufer/LrMediaWiki/issues/35 – Support servers without structured data (enhancement)
• https://github.com/Hasenlaeufer/LrMediaWiki/issues/36 – "Caption (en)" should only be set if filled by a value (enhancement)

English: This release introduces a new switch in the settings: “Support structured data”. The switch is switched on by default (e.g. for uploads to Wikimedia Commons). For MediaWiki installations without structured data, the switch should be switched off to avoid error messages.

Deutsch: Dieses Release führt einen neuen Schalter in den Einstellungen ein: „Unterstützung strukturierter Daten“. Standardmäßig (z. B. für Uploads zu Wikimedia Commons) ist der Schalter eingeschaltet. Für MediaWiki-Installationen ohne strukturierte Daten sollte der Schalter ausgeschaltet werden, um Fehlermeldungen zu vermeiden.

Hasenläufer 22:25, 27 February 2021 (UTC)