lama4linux
Anmeldungsdatum: 17. November 2016
Beiträge: 143
|
Im Bereich Am Anfang eines Artikels → Getestet scheint der Beispiel-Code nicht zu dem Beispiel-Ergebnis zu passen. Falls das änderungswürdig ist, wäre die Benutzung aktueller Versionsnummern vielleicht auch ganz hübsch 😉 PS: Artikel Textbausteine ist gemeint
|
Heinrich_Schwietering
Wikiteam
Anmeldungsdatum: 12. November 2005
Beiträge: 11324
Wohnort: Bremen
|
Hi! Ja, da hast du völlig recht; liegt daran, dass nur noch precise in der dazugehörigen Vorlage noch Unterstützung hat(te). Werde das auf neuere Versionen umstellen. Danke für den Hinweis! so long hank
|
linux_joy
Anmeldungsdatum: 6. Februar 2008
Beiträge: 752
Wohnort: Hannover
|
Hallo,
Besonderheiten
Code: [[Vorlage(Getestet, general)]]
Ergebnis:
Dieser Artikel wurde für die folgenden
Ubuntu-Versionen getestet:
Dieser Artikel ist größtenteils für alle Ubuntu-Versionen gültig.
Nur dann einzusetzen, wenn der Artikel allgemein gültig ist. Das können in der Regel nur Konzepte (Booten, Dienste, usw.) sein, Programme sind fast immer versionsabhängig. Eine Ausnahme stellen beispielsweise die grundlegenden Werkzeuge coreutils und viele Shell-Befehle dar, die aus Kompatibilitätsgründen sehr selten geändert werden. Hinweis:Bitte beachten: "Getestet, general" ist nicht das gleiche wie "Getestet, (alle aktuellen Ubuntu-Versionen)"!
▶ Wo ist denn das entsprechende Makro für "Getestet, (alle aktuellen Ubuntu-Versionen)"? Oder war es früher mal da und der Hinweis ist veraltet? Code: [[Vorlage(Getestet, )]]
Ergebnis:
Dieser Artikel wurde für die folgenden
Ubuntu-Versionen getestet:
Dieser Artikel ist mit keiner aktuell unterstützten Ubuntu-Version getestet! Bitte teste diesen Artikel für eine Ubuntu-Version, welche aktuell unterstützt wird. Dazu sind die Hinweise zum Testen von Artikeln zu beachten.
Diese Markierung darf ausschließlich gesetzt werden, wenn ein Artikel mit der Zeit veraltet ist und nach und nach alle anderen Ubuntuversionen aus dem Getestet -Makro herausgefallen sind. Artikel mit "ungetestet"-Markierung bleiben dann noch bis zu sechs Monate im Wiki und werden anschließend ins Archiv verschoben. Wird diese Vorlage im Sinne von "ungetestet" benutzt, so ist auch gleichzeitig in der zugehörigen Diskussion ein entsprechender Hinweis zu veröffentlichen.
▶ Mein Vorschlag hierzu wäre, direkt im Makro an den anzuzeigenden Text einen Satz anzuhängen, der auf die Sechs-Monats-Frist hinweist, etwa so: "Falls dies nicht bis zum ... geschieht wird der Artikel ins Archiv verschoben. Von dort könnte er allerdings nach erneuter Testung auch wieder zurück ins normale Wiki verschoben werden." Für "..." sollte ein automatisch durch Inyoka generiertes Datum stehen. ▶ Außerdem: Statt "getestet-Tag" ▶ "Getestet-Tag"!
|
Heinrich_Schwietering
Wikiteam
Anmeldungsdatum: 12. November 2005
Beiträge: 11324
Wohnort: Bremen
|
Hi! linux_joy schrieb:
▶ Wo ist denn das entsprechende Makro für "Getestet, (alle aktuellen Ubuntu-Versionen)"? Oder war es früher mal da und der Hinweis ist veraltet?
Gibt es nicht, gab es nicht; ist ein "Platzhalter", derzeit für "trusty, xenial, artful, bionic ", den wir sonst bei jedem EOL einer Version ändern müssten.
▶ Mein Vorschlag hierzu wäre, direkt im Makro an den anzuzeigenden Text einen Satz anzuhängen, der auf die Sechs-Monats-Frist hinweist, etwa so: "Falls dies nicht bis zum ... geschieht wird der Artikel ins Archiv verschoben. Von dort könnte er allerdings nach erneuter Testung auch wieder zurück ins normale Wiki verschoben werden."
Könnte man machen, allerdings würden wir uns mit einem festen Termin selbst unter Druck setzen, oder bestimmte User könnten versuchen, uns damit unter Druck zu setzen (so nach dem Motto "warum ist Artikel XY schon im Archiv, aber XZ noch nicht? Das ist doch unfair, ihr bevorzugt doch bestimmt XZ! ) Für "..." sollte ein automatisch durch Inyoka generiertes Datum stehen.
Wäre was fürs Webteam, aber ich denke, das hat nicht die höchste Priorität, zudem: s.o. ▶ Außerdem: Statt "getestet-Tag" ▶ "Getestet-Tag"!
Hm? Ggf. ein Schreibfehler. Hat sich so eingebürgert, kann man ggf. ändern, weiß aber gerade nicht, wie die entsprechende Vorlage bearbeitet werden kann. so long hank
|
noisefloor
Anmeldungsdatum: 6. Juni 2006
Beiträge: 29567
|
Hallo,
Mein Vorschlag hierzu wäre, direkt im Makro an den anzuzeigenden Text einen Satz anzuhängen, der auf die Sechs-Monats-Frist hinweist, etwa so:
Was soll denn deiner Meinung nach dadurch "besser" werden? Gruß, noisefloor
|
noisefloor
Anmeldungsdatum: 6. Juni 2006
Beiträge: 29567
|
Hallo, Heinrich_Schwietering schrieb: ▶ Außerdem: Statt "getestet-Tag" ▶ "Getestet-Tag"!
Hm? Ggf. ein Schreibfehler. Hat sich so eingebürgert, kann man ggf. ändern, weiß aber gerade nicht, wie die entsprechende Vorlage bearbeitet werden kann.
Ich aber 😬 Gruß, noisefloor
|
tomtomtom
Supporter
Anmeldungsdatum: 22. August 2008
Beiträge: 55085
Wohnort: Berlin
|
Moin, der Textbaustein der PPA-Vorlage enthält den Text "Damit Pakete aus dem PPA genutzt werden können, müssen die Paketquellen neu eingelesen werden." Das ist in 18.04 so nicht (mehr) korrekt, da ein sudo add-apt-repository ppa:bla/foo nicht nur dein Eintrag in den Ordner /etc/apt/sources.list.d/ setzt und den gpg-Key herunterlädt und hinzufügt, sondern auch die Quellen neu einliest.
|
BillMaier
Supporter
Anmeldungsdatum: 4. Dezember 2008
Beiträge: 6492
|
Danke für die Info. Bleibt die Frage, wie wir damit umgehen. Ein Einschub wie "müssen die Paketquellen (bis Ubuntu 17.10) neu eingelesen werden" finde ich nicht hilfreich, sondern eher verwirrend. Einmal zu viel einlesen schadet wiederum nicht. Oder hat jemand dazu Vorschläge? Gruß BillMaier
|
noisefloor
Anmeldungsdatum: 6. Juni 2006
Beiträge: 29567
|
Hallo,
Einmal zu viel einlesen schadet wiederum nicht.
+1 und ein Knoten ins Taschentuch, die Vorlage im April 2021 mit dem EOL von Xenial zu ändern ☺ Gruß, noisefloor
|
linux_joy
Anmeldungsdatum: 6. Februar 2008
Beiträge: 752
Wohnort: Hannover
|
Hallo,
Installation via PIPSyntax[[Vorlage(PipInstallation, Python-Paket)]]
Sollte es stattdessen nicht lieber Python-Modul heißen (gemäß pip)?
Sonstige Bausteine
Hier sind Textbausteine aufgeführt, die normalerweise nur vom Wikiteam gesetzt werden, oder veraltet sind. Ausbaufähig-Markierung
Verwendung: Ist ein Artikel unvollständig oder kann noch erweitert werden (wichtig: unvollständig heißt aber trotzdem in sich schlüssig und nicht fehlerhaft!), dann kann man diese Makro nutzen.
Fehlerhaft-Markierung
Verwendung: Stimmen Angaben bzw. ganze Abschnitte in einem Wiki Artikel nicht, so kann dieser mit der "Fehlerhaft"-Markierung versehen werden, die das Problem beschreibt.
Verlassen-Markierung
Verwendung: Diese Markierung wird normalerweise nur für Baustellen Artikel genutzt, die der Originalautor nicht mehr zu Ende bringt (warum auch immer). Dieser Artikel kann von jedem Nutzer ohne weitere Rückfragen zu Ende geführt werden.
Überarbeitungs-Markierungen
Wird ein Artikel zur Überarbeitung in die Baustelle verschoben, kommen zwei Vorlagen zum Einsatz:
Die Vorlage "Kopie" wird nur von den Wiki-Moderatoren benötigt um den Artikel zu markieren, der als Originalkopie einer Seite im normalen Wiki verbleibt. Die Vorlage "Überarbeitung" ist für die Baustelle, in der der Artikel überarbeitet wird.
Fremdquelle-, Fremdpakete- und Fremdsoftware-Warnung
Verwendung: Ein "Muss" für Pakete, die nicht aus den offiziellen Paketquellen von Ubuntu stammen. Ebenso ist die Warnung einzusetzen, wenn die manuelle Installation von Fremdsoftware beschrieben wird, z.B. über ein Installations-Skript. "Kommentar" ist immer optional und kann auch komplett weggelassen werden.
Der einleitende Satz: Hier sind Textbausteine aufgeführt, die normalerweise nur vom Wikiteam gesetzt werden, oder veraltet sind.
ist IMHO zu unspezifisch. Sind etwa Fremdquelle-, Fremdpakete- und Fremdsoftware-Warnung
veraltet oder sollen normalerweise nur vom Wikiteam gesetzt werden? Beides trifft hier aber NICHT zu! Außerdem ist IMHO das 2. Komma überflüssig. Meine Vorschläge:
Einleitungs-Satz abändern in: Hier sind Textbausteine aufgeführt, die normalerweise nur vom Wikiteam gesetzt werden, oder veraltet sind. Falls jedoch in der Beschreibung zum jeweiligen Textbaustein nicht ausdrücklich vermerkt ist, dass er nur vom Wikiteam gesetzt werden darf, so kann er auch von normalen Benutzern verwendet werden. In den Einleitungs-Sätzen zu den jeweiligen Textbausteinen sollte folglich ausdrücklich vermerkt werden, ob sie (normalerweise) nur vom Wikiteam gesetzt werden oder veraltet sind! == Fremdquelle-, Fremdpakete- und Fremdsoftware-Warnung == sollte IMHO ein eigener Haupt-Abschnitt werden, und zwar oberhalb = Sonstige Bausteine = oder – noch besser – es wird der letzte Unter-Abschnitt von = Paketinstallation = Grund: "Fremd-"Dinger sind weder veraltet, noch werden sie normalerweise nur vom Wikiteam gesetzt.
Mir geht es bei den letztgenannten Vorschlägen hauptsächlich um die Ausbaufähig-, Fehlerhaft- und Verlassen-Markierungen. Diese sollen IMHO auch von normalen Benutzern verwendet werden dürfen! Oder sind sie wirklich veraltet oder werden normalerweise nur vom Wikiteam gesetzt?
|
noisefloor
Anmeldungsdatum: 6. Juni 2006
Beiträge: 29567
|
Hallo,
Sollte es stattdessen nicht lieber ...
Geändert.
Der einleitende Satz: ... ist IMHO zu unspezifisch. Sind etwa ...
Geändert. Keine Ahnung, warum es an der Stelle stand. Selbst historisch gesehen war es AFAIR nie so.
Diese sollen IMHO auch von normalen Benutzern verwendet werden dürfen! Oder sind sie wirklich veraltet oder werden normalerweise nur vom Wikiteam gesetzt?
Nein, aber um Wildwuchs und "Wild-West-Style" Markierungen zu vermeiden, ist das schon so, wie es da steht. Wir (=das Wikiteam) hat zwar immer das letzte Wort, aber hier ist der explizite Hinweis, dass wir das letzte Wort haben, gewünscht. Gruß, noisefloor
|
linux_joy
Anmeldungsdatum: 6. Februar 2008
Beiträge: 752
Wohnort: Hannover
|
Hallo zusammen, vielen Dank für die weitgehende Berücksichtigung meiner Vorschläge ☺ Aber:
noisefloor schrieb:
(...)
Diese sollen IMHO auch von normalen Benutzern verwendet werden dürfen! Oder sind sie wirklich veraltet oder werden normalerweise nur vom Wikiteam gesetzt?
Nein, aber um Wildwuchs und "Wild-West-Style" Markierungen zu vermeiden, ist das schon so, wie es da steht. Wir (=das Wikiteam) hat zwar immer das letzte Wort, aber hier ist der explizite Hinweis, dass wir das letzte Wort haben, gewünscht.
Die einzige vorgenommene Änderung im 1. Satz ist die, das "nur" zu unterstreichen ⇒ soll IMHO also bedeuten, dass normale Benutzer die Finger auch von den Ausbaufähig-, Fehlerhaft- und Verlassen-Markierungen zu lassen haben! Aber veraltet, wie oben vllt. vermutet, scheinen sie ja auch nicht zu sein. Gilt das "veraltet" dann etwa für die Überarbeitungs-Markierungen? Wohl eher auch nicht. <Bearbeitung 15.10.19, 00:55> Jetzt verstehe ich wohl endlich, was mit dem "veraltet" gemeint sein muss: Am Ende des Haupt-Abschnittes stehen die folgenden auskommentierten Zeilen:
##aasche: wird seit Jahren nicht mehr genutzt...
##= andere Seiten einbinden =
##Grundsätzlich ist es auch möglich, den Inhalt anderer Wikiseiten komplett auf der aktuellen Seite einzubinden. Die Darstellung erfolgt so, dass der Leser der Seite nicht sieht, dass der Inhalt von einer anderen Seite eingebunden wurde. Der Vorteil des Einbindens ist, dass Informationen zentral auf einer Seite gepflegt werden, aber in vielen Artikel genutzt (eingebunden) werden können.
##=== Syntax ===
##``[[Einbinden(Seitenname)]]``
##Zu beachten ist, dass immer der Inhalt der gesamten Seite eingebunden wird!
Also weg mit dem "veraltet" ❗ </Bearbeitung> Als Ergänzung für den 1. Satz möchte ich aber auf jeden Fall den folgenden Satz vorschlagen: Falls jedoch ein normaler Benutzer einen oder mehrere Gründe für die Verwendung der __Ausbaufähig-, Fehlerhaft- und Verlassen-Markierungen__ in irgendeinem Wiki-Artikel wünscht, so kann er dies in der jeweiligen Artikel-Diskussion anbringen.
Gruß, noisefloor
Fremdquelle-, Fremdpakete- und Fremdsoftware-Warnung
Änderungs-Vorschlag für den 2. Satz: "... Bei der Verwendung der oben aufgeführten Vorlagen zur Paketinstallation ..."
|
linux_joy
Anmeldungsdatum: 6. Februar 2008
Beiträge: 752
Wohnort: Hannover
|
Hallo zusammen, betr. "Getestet"-Baustein: Bitte Korrektur davon:
[[Vorlage(Getestet, Ubuntuversion(en])]]
|
linux_joy
Anmeldungsdatum: 6. Februar 2008
Beiträge: 752
Wohnort: Hannover
|
Hallo zusammen,
Wissensblock
(...)
Automatischer Link zum Wissensblock im Artikeltext
Im Text verwendet man einfach die entsprechende Nummer in eckigen Klammern als Verweis auf den Wissensblock. Inyoka setzt dann automatisch den entsprechenden Link. Code:
... Das Paket '''foo''' kann dann einfach installiert[1] werden. Ergebnis: "... Das Paket foo kann dann einfach installiert[1] werden." Dabei reicht es, ein Mal - beim ersten Vorkommen eines im Wissensblock aufgeführten Eintrags - einen Verweis zu setzen.
Was heißt denn hier bitteschön "es reicht, ein Mal - beim ersten Vorkommen eines im Wissensblock aufgeführten Eintrags - einen Verweis zu setzen."? Dass man sich guten Gewissens weitere Verweise sparen kann, oder dass es sogar unerwünscht ist, weitere Verweise zu setzen? Ich persönlich finde, in längeren Artikeln sollte mindestens einmal pro (Haupt)-Abschnitt ein Verweis gesetzt werden! → Also Text-Vorschlag: Dabei reicht es, ein Mal – beim ersten Vorkommen eines im Wissensblock aufgeführten Eintrags – einen Verweis zu setzen. Für längere Artikel gilt sinngemäß: mindestens einmal pro (Haupt)-Abschnitt. In Wiki/Referenz (Abschnitt „Wahl-der-Werkzeuge“) steht betr. "Verweis auf den Wissensblock": > "in der Anleitung selbst genügt jetzt eine allgemeine Formulierung. →(Bild) " Neben der Tatsache, dass der Satz mit einem Kleinbuchstaben beginnt, ist auf dem besagten Bild im Unterschied zu hier der Verweis mit einem Leerzeichen hinter dem Text dargestellt. Was ist denn jetzt richtig(er): Leerzeichen oder Nicht-Leerzeichen? Ich nehme allerdings "Nicht-Leerzeichen" an, da das besagte Bild schon "älteres Semester" zu sein scheint.
|
linux_joy
Anmeldungsdatum: 6. Februar 2008
Beiträge: 752
Wohnort: Hannover
|
Hallo zusammen, Ergänzungs-Vorschlag:
Pakete-MakroHinweis:Der Textbaustein Pakete-Makro sollte normalerweise nicht mehr verwendet werden. Siehe Textbaustein Paketinstallation.
|