Diese Seite ist ein Archiv abgeschlossener Diskussionen. Ihr Inhalt sollte daher nicht mehr verändert werden. Benutze bitte die aktuelle Diskussionsseite, auch um eine archivierte Diskussion weiterzuführen.
Um einen Abschnitt dieser Seite zu verlinken, klicke im Inhaltsverzeichnis auf den Abschnitt und kopiere dann Seitenname und Abschnittsüberschrift aus der Adresszeile deines Browsers, beispielsweise
]
|
(Apologies if this message isn't in your language. Please consider translating it, as well as the full version of this announcement on Meta)
The Wikimedia Foundation is planning to do limited testing of IPv6 on June 2-3. If there are not too many problems, we may fully enable IPv6 on World IPv6 day (June 6), and keep it enabled.
What this means for your project:
2001:0db8:85a3:0000:0000:8a2e:0370:7334
". See e.g. w:en:IPv6 address. These addresses should behave like any other IP address: You can leave messages on their talk pages; you can track their contributions; you can block them. (See the full version of this announcement for notes on range blocks.)Read the full version of this announcement on how to test the behavior of IPv6 with various tools and how to leave bug reports, and to find a fuller analysis of the implications of the IPv6 migration.
--Erik Möller, VP of Engineering and Product Development, Wikimedia Foundation 02:52, 2. Jun 2012 (MESZ)
Distributed via Global message delivery. (Wrong page? Fix here.)
2001:0db8:85a3:0000:0000:8a2e:0370:7334
". Siehe auch w:de:IPv6. Diese Adressen sollten sich wie die anderen IPs verhalten: Es können Nachrichten auf der Diskussionsseite hinterlassen werden, die Beiträge können verfolgt werden und sie können gesperrt werden. (siehe the full version of this announcement für Hinweise auf Range-Blöcke.)македонски • norsk • polski
Dear Wikimedians,
Wikimedia Commons is happy to announce that the 2011 Picture of the Year competition is now open. We are interested in your opinion as to which images qualify to be the Picture of the Year 2011. Any user registered at Commons or a Wikimedia wiki SUL-related to Commons with more than 75 edits before 1 April 2012 (UTC) is welcome to vote and, of course everyone is welcome to view!
Detailed information about the contest can be found at the introductory page.
About 600 of the best of Wikimedia Common's photos, animations, movies and graphics were chosen –by the international Wikimedia Commons community– out of 12 million files during 2011 and are now called Featured Pictures.
From professional animal and plant shots to breathtaking panoramas and skylines, restorations of historically relevant images, images portraying the world's best architecture, maps, emblems, diagrams created with the most modern technology, and impressive human portraits, Commons Features Pictures of all flavors.
For your convenience, we have sorted the images into topic categories.
We regret that you receive this message in English; we intended to use banners to notify you in your native language but there was both, human and technical resistance.
See you on Commons! --Picture of the Year 2011 Committee 20:11, 5. Jun 2012 (MESZ)
Distributed via Global message delivery. (Wrong page? Fix here.)
(Apologies if this message isn't in your language. Please consider translating it, as well as the instructions on Meta)
The mobile view of this project and others will soon become the default view on mobile devices (except tablets). Some language versions of these projects currently show no content on the mobile home page, and it is a good time to do a little formatting so users get a mobile-friendly view, or to add to existing mobile content if some already exists.
If you are an administrator, please consider helping with this change. There are instructions which are being translated. The proposed date of switching the default view is June 21.
To contact the mobile team, email mobile-feedback-llists.wikimedia.org
.
--Phil Inje Chang, Product Manager, Mobile, Wikimedia Foundation 10:27, 16. Jun 2012 (MESZ)
Distributed via Global message delivery. (Wrong page? Fix here.)
Einige Benutzer des Wiktionary schreiben eigene kleine Javascript-Funktionen, die allerdings zu Konflikten führen können, wenn zusätzlich noch weitere Skripte anderer Benutzer eingebunden werden. Das Problem dabei sind die im Javascript-Code global definierten Namen von Funktionen und Variablen. Ist in einem Skript eines anderen Benutzers zufällig der gleiche Name, den man auch im eigenen Skript benutzt, ebenfalls definiert, führt das zu Problemen. Bestenfalls funktioniert die eingebundene Methode einfach nicht, schlechtestenfalls führt ein Methodenaufruf zu unbemerkten falschen Resultaten. Da jedoch auch immer die Seite MediaWiki:Common.js automatisch eingebunden wird, und dort ebenfalls zahlreiche globale Funktionen und Variablen definiert werden, kann es bereits zu Problemen kommen, wenn man nur eigene und keine Skripte anderer benutzt.
Die Lösung des Problems nennt sich Modularisierung. Dazu definiert man die eigenen Funktionen nicht mehr global sondern innerhalb eines eigenen Objekts. Dieses ist dann zwar immer noch global, jedoch hat man das Namenskonfliktpotential auf ein einziges Objekt reduziert. Der Aufruf erfolgt dann immer über dieses eigene Objekt. Also sei "meinGlobalesObjekt" der Name dieses neuen Objekts, dann erfolgt der Aufruf statt mit: myFunc1() oder myFunc2() mit meinGlobalesObjekt.myFunc1() bzw. meinGlobalesObjekt.myFunc2(). Das sieht zunächst einmal etwas kompliziert aus, hat aber den Vorteil, dass man bei Namenskonflikten nur ein einziges Objekt prüfen muss, während man sonst erst lange die Konfliktursache suchen muss. Sollte hier doch einmal ein Konflikt auftreten, kann man einfach "meinGlobalesObjekt" in "mGO" oder anderes umbenennen, um den Konflikt zu beseitigen. Um die Modularisierung zu erreichen, genügt eine einfache Schablone:
// die Definition des Objekts auf der .js Seite beginnt immer mit: (function( _public, $, undefined ) {
// eigene Funktionen, die global aufrufbar sein sollen, beginnen // (wobei die Funktion ggf. auch Parameter haben kann) mit _public.analyzePage = function() { ... }
// interne Funktionen (Hilfsfunktionen) schreibt man wie gewohnt function myHelper(param1, ...) { ... }
// die Definition des Objekts auf der .js Seite endet immer mit: // der Name meinGlobalesObjekt ist dabei durch einen eigenen Namen zu ersetzen }( window.meinGlobalesObjekt = window.meinGlobalesObjekt || {}, jQuery ));
Diese Art der Definition stellt zusätzlich sicher, das jQuery innerhalb des eigenen Moduls immer mit "$" angesprochen werden kann und dass das Objekt "undefined" immer in Sinne seines Namens verwendet werden kann. Eine Beispielanwendung ist Benutzer:Formatierer/checkpage.js. Wer weitere Informationen zum Thema sucht, findet hier einen guten Überblick. -- Formatierer (Diskussion) 12:32, 17. Jun 2012 (MESZ)
Zuerst hatte ich Probleme mir deine Buttons überhaupt anzeigen zu lassen. Man darf allerdings unter "Einstellungen / Bearbeiten / Beta-Funktionen" kein Häkchen bei "Erweiterte Bearbeiten-Werkzeugleiste aktivieren" machen. Nun, da ich das Häkchen entfernt habe, gehts bei mir aber auch. Der erste Teil, deine persönlichen Javascript-Methoden nicht mehr global sichtbar zu haben, hat ja bestens funktioniert. Nun muss noch der Kopf deiner Funktion
function loadButtons()
damit sie außerhalb von "begin namespace" und "end namespace" aufgerufen werden kann, so geschrieben werden:
_public.loadButtons = function ()
Am Ende deines buttons.js muss es nun heißen:
addLoadEvent( buttons.loadButtons );
Funktionsaufrufe per Mausklick müssen nun ebenfalls über dieses globale Objekt erfolgen, also müssen alle href=javascript:funcX() in href="javascript:buttons.funcX()" geändert werden. Alle diese Funktionen müssen nach obigem Schema definiert werden, also:
_public.funcX = function ()
Ich habe das hier mal exemplarisch für zwei Funktionen durchgeführt: Benutzer:Formatierer/common.js Für dein globales Objekt, über das du deine Funktionen aufrufen kannst, hast du den Namen "buttons" gewählt. In deiner Funktion loadButtons hast du auch eine "var buttons" definiert. Das kann man leicht verwechseln. Ich empfehle deshalb dein globales Objekt lieber "bkbuttons" zu nennen. Außerdem wird in der Funktion immer versucht auf toolbox.innerHTML zuzugreifen. Besser wäre es, am Anfang der Funktion zunächst einmal zu prüfen, ob toolbox überhaupt einen Wert != null hat (siehe meine common.js) und dann erst die Buttonleiste zusammenzubauen. -- Formatierer (Diskussion) 17:27, 19. Jun 2012 (MESZ)
Hallo zusammen,
Was mir schon länger auf dem Herzen liegt: Es gefällt mir nicht wirklich, dass wir Meta-Begriffe, die wir in den Einträgen verwenden, auf Einträge verlinken. Beispiele: transitiv, reflexiv, umgangssprachlich, veraltet, Kompositum, Suffix. Dies drängt diesen Einträgen eine Meta-Erklärungsfunktion auf, die sie eigentlich als normale Wörterbucheinträge nicht haben sollten. Wäre es nicht besser, diese Begriffe auf Abschnitte verschiedener Erklärungsseiten (Hilfe: oder Wiktionary:) zu verlinken?
Viele Grüße, Kronf (Diskussion) 03:12, 3. Jun 2012 (MESZ)
Der Punkt von Jonathan "@79.239.165.81": ja. Zum andere Punkt ("@79.239.189.140", mangelnde Unterscheidbarkeit der Links): Wenn wir auf Schwesterprojekte wie WP verlinken, dann wie YS unten geschrieben – dann ist der Link hellblau und ohne das Hinweissymbol.
Dem Beispiel Aas entnehme ich, dass du insbes. Sprachnamen in die WP verlinken würdest. Ich verstehe, dass das Sinn macht. Vielleicht könnte man die Links grün schreiben, dann hätte ich nichts dagegen (außer dass es sehr bunt wäre). Ich würde daher eher dazu tendieren, zumindest europäische Sprachen überhaupt nicht zu verlinken; wenn man mehr wissen möchte, gohgält man es eben. Ich schreibe mal was in die Wiktionary:Spielwiese.
Oder wir legen Hilfe/Infoseiten an, die nur die Definition des Ausdrucks angeben, wie wir in hier praktisch und konkret verwenden und verweisen für weitere allgemeine Infos in die WP oder so. Beträfe Ausdrücke wie "umgangssprachlich". 79.239.186.90 17:37, 1. Okt. 2012 (MESZ)
hierher hochverschoben --79.239.182.171 18:51, 10. Okt. 2012 (MESZ)
Ich möchte in einem Artikel betstimmte Begriffe, die dem Benutzer des Wörterbuchs möglicherweise unbekannt sind (etwa Partizip Perfekt oder mittelhochdeutsch), erklärend verlinken. Zum Teil gibt es keinen Wiktionary-Eintrag zu diesen Begriffen. Ein WT-Link schiene mir überdies unpassend, da ja nicht auf die Sprach- sondern auf die Sachinformationen verwiesen werden soll. Darf ich dazu (etwa im Abschnitt "Herkunft") in die Wikipedia verlinken? Jonathan (Diskussion) 14:07, 29. Sep 2012 (MESZ)
Momääänt…! Ich sehe da ein Problem. Kannst du, Jonathan, ein konkretes Beispiel (Eintrag) geben für was du vor hast?
Das Thema steht bereits weiter oben (wäre diese Seite nicht so furchtbar groß, käme man da sogar drauf) im Abschnitt #Meta-Begriffe_auf_Hilfeseiten_statt_auf_Eintr.C3.A4ge_verlinken; man beachte insbes. meinen letzter Kommentar. --79.239.157.216 16:12, 30. Sep 2012 (MESZ)
{{W}}
? Zumindest habe ich die kürzlich erst in Übersprunghandlung wieder benutzt. Die Verwendung der Vorlage hätte meiner Meinung nach den Riesenvorteil, dass eine Designanpassung der WP-Links (die vermutl. tatsächlich sinnvoll wäre) global über die Vorlage erfolgen kann. Wenn man über ] verlinkt, kann man die WP-Links von den internen Wikt-Links kaum unterscheiden. --Stepro (Diskussion) 20:52, 4. Okt. 2012 (MESZ)Es bleibt mangels Gegenvorschlägen beim Status quo. 217.252.101.62 08:34, 31. Okt. 2012 (MEZ)
Zur Info: Diese Idee dürfte Wiktionary recht stark betreffen: Sprachausgabe von Lautschrift. --Stepro (Diskussion) 01:38, 4. Jun 2012 (MESZ)
Liebe Leute!
Viele von uns sind sich bewusst, dass unsere Wiedergabe der Aussprache nicht ganz optimal ist. Am meisten hat sich Caligari darüber Gedanken gemacht; ich würde ihm gerne das Feld überlassen. Leider habe ich längere Zeit nichts von ihm gesehen und ich weiß nicht, ob er sich in absehbarer Zeit wieder hier einklinken wird oder ob er sich - aus welchen Gründen auch immer - verabschiedet hat.
Ich will nun aber auch nichts über's Knie brechen und noch eine Weile warten. Andererseits will ich aber auch schon mal andeuten, in welche Richtung meine Gedanken gehen: Grundsätzlich wäre ich für eine Annäherung an Duden. Aussprachewörterbuch unter gelegentlicher Berücksichtigung von Krech, Stock und andere, Deutsches Aussprachewörterbuch. Keines davon können wir einfach nachahmen, da uns teilweise die entsprechenden Zeichen fehlen; Krech u.a. erscheint mir für ein Wörterbuch, das sich nicht vornehmlich an geschulte Phonetiker wendet, als viel zu komplex, Duden erscheint mir als publikumsnäher. Problemfälle, bei denen wir wohl etwas umstellen müssen, sind der Ach-Laut, die Diphthonge und vor allem die r-Laute. Meine Intention ist dabei, möglichst wenig gegenüber unserer bisherigen IPA-Hilfe zu ändern. Nach anfänglichen Problemen habe ich allerdings die Wiedergabe von Schwa oder Nicht-Schwa den beiden genannten Aussprachewörterbüchern angenähert; die Angabe in der IPA-Hilfe müsste aber noch angepasst werden.
Eine weitere Idee ist, die Angabe von Varianten zu reduzieren; wir haben in vielen Fällen neben Transkriptionen, die mit den genannten Aussprachewörterbüchern übereinstimmen, noch assimilierte Formen angeben. Ich persönlich halte sie für richtig, aber nicht für nötig, da sie sich beim Sprechen automatisch einstellen, und zwar um so mehr, je schneller man spricht.
Wohl gemerkt: Dies ist jetzt nicht die Ankündigung unmittelbar bevorstehender Änderungen, die ich natürlich auch keinesfalls im Alleingang angehen würde; mich würde aber doch interessieren, was diejenigen, die sich um die Transkriptionen kümmern, von einer solchen Perspektive halten. Vorläufig bleibe ich - mit der einen kleinen genannten Abweichung - bei den derzeitigen Regeln, die in der IPA-Hilfe stehen. Da jedes Wörterbuch wieder etwas andere Transkriptionsregeln verwendet, scheint es mir am wichtigsten zu sein, dass man sich an die angegebenen Regeln hält und weniger, welches Zeichen genau man für einen bestimmten Fall einsetzt.
Grüß Euch! Dr. Karl-Heinz Best (Diskussion) 11:08, 7. Jun 2012 (MESZ)
Weitere Diskussion unter Wiktionary:Teestube#Neue IPA-Regelung. --Kronf (Diskussion) 12:38, 22. Jul. 2014 (MESZ)