Wikisource:Skriptoriet
|
 .orgLæs seneste udgave Abonner Har du nyheder? skriv til os (engelsk) |
| Arkiverede debatter |
Velkommen nybegyndere og andre forundrede brugere. Dette er stedet, hvor man kan stille spørgsmål eller komme med kommentarer om alt vedrørende Wikisource. Før du stiller et spørgsmål, så check lige om det ikke allerede er besvaret under ofte stillede spørgsmål.
For at lette navigationen og besvarelsen af spørgsmål bedes du:
- Placere nye spørgsmål eller kommentarer i bunden af listen.
- Give spørgsmålet/kommentaren en titel (ved at skrive ==titel== umiddelbart før dit indlæg).
- Signere dit indlæg med navn og dato (ved at skrive ~~~~ eller bruge menuliniens signaturknap).
On behalf of the Wikimedia Foundation Elections Committee, we are pleased to announce that self-nominations are being accepted for the 2017 Wikimedia Foundation Funds Dissemination Committee and Funds Dissemination Committee Ombudsperson elections. Please read the letter from the Wikimedia Foundation calling for candidates at on the 2017 Wikimedia Foundation elections portal.
Funds Dissemination Committee
The Funds Dissemination Committee (FDC) makes recommendations about how to allocate Wikimedia movement funds to eligible entities. There are five positions being filled. More information about this role can be found at the FDC elections page.
Funds Dissemination Committee Ombudsperson
The Funds Dissemination Committee Ombudsperson receives complaints and feedback about the FDC process, investigates complaints at the request of the Board of Trustees, and summarizes the investigations and feedback for the Board of Trustees on an annual basis. One position is being filled. More information about this role can be found at the FDC Ombudsperson elections page.
The candidacy submission phase will last until May 28 (23:59 UTC).
We will also be accepting questions to ask the candidates until May 28. You can submit your questions on Meta-Wiki. Once the questions submission period has ended on May 28, the Elections Committee will then collate the questions for the candidates to respond to.
The goal of this process is to fill the five community-selected seats on the Wikimedia Foundation Funds Dissemination Committee and the community-selected ombudsperson. The election results will be used by the Board itself to make the appointments.
The full schedule for the FDC elections is as follows. All dates are inclusive, that is, from the beginning of the first day (UTC) to the end of the last.
- May 15 (00:00 UTC) – May 28 (23:59 UTC) – Nominations
- May 15 – May 28 – Candidates questions submission period
- May 29 – June 2 – Candidates answer questions
- June 3 – June 11 – Voting period
- June 12–14 – Vote checking
- June 15 – Goal date for announcing election results
More information on this year's elections can be found at the 2017 Wikimedia Foundation elections portal.
Please feel free to post a note about the election on your project's village pump. Any questions related to the election can be posted on the talk page on Meta-Wiki, or sent to the election committee's mailing list, board-elections
wikimedia.org.
On behalf of the Election Committee,
Katie Chan, Chair, Wikimedia Foundation Elections Committee
Joe Sutherland, Community Advocate, Wikimedia Foundation
23. maj 2017, 21:06 (UTC)
Improved search in deleted pages archive
Hjælp venligst med at oversætte til dit sprog
During Wikimedia Hackathon 2016, the Discovery team worked on one of the items on the 2015 community wishlist, namely enabling searching the archive of deleted pages. This feature is now ready for production deployment, and will be enabled on all wikis, except Wikidata.
Right now, the feature is behind a feature flag - to use it on your wiki, please go to the Special:Undelete page, and add &fuzzy=1 to the URL, like this: https://test.wikipedia.org/w/index.php?title=Special%3AUndelete&fuzzy=1. Then search for the pages you're interested in. There should be more results than before, due to using ElasticSearch indexing (via the CirrusSearch extension).
We plan to enable this improved search by default on all wikis soon (around August 1, 2017). If you have any objections to this - please raise them with the Discovery team via email or on this announcement's discussion page. Like most Mediawiki configuration parameters, the functionality can be configured per wiki.
Once the improved search becomes the default, you can still access the old mode using &fuzzy=0 in the URL, like this: https://test.wikipedia.org/w/index.php?title=Special%3AUndelete&fuzzy=0
Please note that since Special:Undelete is an admin-only feature, this search capability is also only accessible to wiki admins.
Tak! CKoerner (WMF) (talk) 25. jul 2017, 18:40 (UTC)
Accessible editing buttons
You can see and use the old and new versions now. Most editors will only notice that some buttons are slightly larger and have different colors.
- Comparison of old and new styles
-
Buttons before the change -
Buttons after the change
However, this change also affects some user scripts and gadgets. Unfortunately, some of them may not work well in the new system. If you maintain any user scripts or gadgets that are used for editing, please see mw:Contributors/Projects/Accessible editing buttons for information on how to test and fix your scripts. Outdated scripts can be tested and fixed now.
This change will probably reach this wiki on Tuesday, 1 August 2017. Please leave a note at mw:Talk:Contributors/Projects/Accessible editing buttons if you need help.--Whatamidoing (WMF) (talk) 27. jul 2017, 16:56 (UTC)
New print to pdf feature for mobile web readers
New print to pdf feature for mobile web readers
The Readers web team will be deploying a new feature this week to make it easier to download PDF versions of articles on the mobile website.
Providing better offline functionality was one of the highlighted areas from the research done by the New Readers team in Mexico, Nigeria, and India. The teams created a prototype for mobile PDFs which was evaluated by user research and community feedback. The prototype evaluation received positive feedback and results, so development continued.
For the initial deployment, the feature will be available to Google Chrome browsers on Android. Support for other mobile browsers to come in the future. For Chrome, the feature will use the native Android print functionality. Users can choose to download a webpage as a PDF. Mobile print styles will be used for these PDFs to ensure optimal readability for smaller screens.
The feature is available starting Wednesday, Nov 15. For more information, see the project page on MediaWiki.org.
Tak!
CKoerner (WMF) (talk) 20. nov 2017, 22:07 (UTC)
Wikisource har en del danske domme, kendelser og andre retsdokumenter, hvoraf de fleste er oprettet af TorbenTT og nogle få af mig selv. De tilhørende sider er navngivet på mange forskellige måder:
- Nogen bruger sagens kaldenavn (Maastrichtsagen)
- Nogen bruger <domstols> dom af <dato> i <sagsnummer> (Retten i Nibes dom af 12. januar 2001 i sag nr. SS 240-2000)
- Nogen bruger partsnavnene (Københavns Havn A/S mod Trafikministeriet)
- Nogen bruger <domstols> dom af <dato> i <sagsnummer> og partsnavne (Østre Landsrets kendelse af 14. september 2000. 3. afd. nr. B-0855-00: Folkebevægelsen mod EU m.fl. mod Statsminister Poul Nyrup Rasmussen)
Med henblik på at mindske forvirring foreslår jeg at vi forsøger at finde på en standardisering af hvordan domme og kendelser navngives. Jeg har 3 bud på hvordan vi kan gøre:
- Kaldenavn hvis muligt, ellers sagsnummer
- Hvis sagen har et almindeligt kendt kaldenavn anvendes dette, f.eks. Maastrichtsagen. Hvis der ikke er noget almindeligt kaldenavn bruges det "lange format", enten <domstol>s dom af <dato> i <sagsnummer> eller <domstol>s dom af <dato> i <sagsnummer>, <partsnavne>.
- Altid sagsnummer, kaldenavn omdirigerer til sagsnummer
- Alle sager angives i det "lange format" og kaldenavene omdirigerer til disse.
- Altid sagsnummer, kaldenavnet står i parentes
- Alle sager angives i det "lange format", men kaldenavnet angives i parentes til sidst. F.eks. Højesterets dom af 13. februar 1989 i sag nr. I 279/1988, Rigsadvokaten mod Jens Olaf Jersild og Lasse Jensen (Grønjakkesagen). Der omdirigeres stadigvæk fra kaldenavnet.
Personligt er jeg mest til nr. 3 eller nr. 2. Kaldenavne er hvordan sagerne kendes i offentligheden, men de er ikke officielle. Derfor synes jeg det er et fint kompromis at der omdirigeres til sagens korrekte navn med sagsnummer og muligvis partsnavne og at kaldenavnet evt. står i parentes til sidst. Hvis der er opbakning til et af disse bør vi også beslutte en standardisering af det "lange format", der er f.eks. forskel på hvordan de ovennævnte domme fra år 2000 og 1988 er formateret. Jeg ser frem til at høre jeres feedback. InsaneHacker (diskussion) 24. nov 2017, 12:21 (UTC)
- Tak for at rejse spørgsmålet. Ja det er lidt svært hvad man skal kalde dem når de ikke har noget rigtigt navn, vi har jo ikke som i f.eks. de engelsksprogede lande et fast systematik for navngivning af domme. Det er vel rigtigt at kaldenavnet ikke er officielt for de har ikke noget officielt navn som sådan. Sagsnumre bruges vel officielt af retten selv og parterne i sagen men praktikere næsten aldrig når der henvises til afgørelser.
- Standard praksis i dansk retslitteratur er at henvise til <tidskrift fortortelse>.<årgang>.<sidetal><forkortelse af instans og evt. afgørelsestype> og ofte også et kaldenavn hvis det findes. Sagnumre bruges stort set aldrig dog nogen gange ved henvisning til utrykte afgørelser, og selv her henvises der oftest kun til instans og dato. At følge denne praksis er jo også en mulighed (Dette rejser jo i øvrigt det spørgsmål hvilket man skal vælge hvis de er trykt flere tidsskrifter hvilket de ofte på visse områder. f. eks. TfS og SKM på skatteområdet). De fleste afgørelser her er ikke taget fra tidsskrifterne men domsudskrifter. Og hos dem der er er domshovedet og noter fjernet grundet udgiverns ophavsret til disse.
- Problemet med sags dato og nr. er at det intet siger om sagen. Sagsnummeret er en teknisk detalje som ikke er specielt interresant og som de færreste husker. Det vil altså betyde at for at finde frem til afgørelsen her på wikisource først skal slå op hvad sagsnr. den har eller dato den er afsagt. Dem der kender sagen eller har hørt om den vil derimod genkende kaldenavnet. Navnene bør gøre det nemt for folk at finde frem til det de søger. Derfor foretrækker jeg kaldenavnene når de forefindes alternativt partsbetegnelsen da den dels er nemmere genkendelig end nogle tal og dels kan sige noget om sagen. Afgørelsessdato og sagsnr. er sidste udvej.
- Højesteret selv har henvist til Maastrictsagen med denne betegnelse i præmisserne for Lissabonsagen, såvel formalitetssagen og realitetssagen henvist til Maastrict-sagen hhv. Maastricht-dommen.
- Partsbetegnelser kan være et alternativ til kaldenavnet. Det er praksis i mange retssystemer at referere til sagerne efter partsbetegnelsen. Det er dog ikke altid brugbart særligt Straffesager er oftest anonymiseret og Anklagemyndigheden mod T indentificerer ikke sagen og siger heller ikke en noget udover at det er en straffesag. Et andet problem er at partbetegnelsen kan variere i løbet af sagen f.eks i grønjakkesagen hvor der i første instans er 3 andre tiltalte. I nogen tilfælde er kaldenavnet navnet på den ene part f.eks. Ove Guldberg-sagen i så fald er det måske bedre at bruge partsbetegnelsen så det er Ove Guldberg mod Indenrigsministeriet?
- Et andet spørgsmål man kan overveje er om der skal anvendes forkortelser, skal vi sige Højesterets dom og Østre Landsrets kendelse eller forkorte de til HD og ØLK?
- I nogen sager er der flere afgørelser i samme sag, f.eks er der i Christianiasagen ud over hovedafgørelsen afsagt 7 højesteretskendelser trykt i ugeskriftet, så for at kunne differencere mellem dem foreslår jeg at der kan tilføres et stikord i parentes til sidst f.eks.: "Xsagen: højesterets kendelse af xx. måned yyyy (Vidneførelse)"
- Mit forslag til en standard
- <kaldenavn eller partsbetegnelse (hvis meningsfuld)>: <instans><dom/kendelse/beslutning> af <dato><sagsnr. (hvis intet kaldenavn eller meningsfuld partbetegnelse)><(evt. supplerende stikord)>.
- Ekempler: Maastrichtsagen -> Maastrichtsagen: Højesterets Dom af 6. april 1998 (Realiteten), Kranførersagen -> Kranførersagen: Vestre Landsrets kendelse af 16. maj 1944, Højesterets dom af 13. februar 1989 i sag nr. I 279/1988, Rigsadvokaten mod Jens Olaf Jersild og Lasse Jensen -> Grønjakkesagen: Højesterets dom af 13. februar 1989, Retten i Nibes dom af 12. januar 2001 i sag nr. SS 240-2000 forbliver som den er. Østre Landsrets kendelse af 14. september 2000. 3. afd. nr. B-0855-00: Folkebevægelsen mod EU m.fl. mod Statsminister Poul Nyrup Rasmussen -> Folkebevægelsen mod EU m.fl. mod Statsminister Poul Nyrup Rasmussen: Østre Landsrets kendelse af 14. september 2000
- Summa summarum altid domstol og dato, kaldenavn eller partbetegnelse når de findes/giver mening, sagsnr kun når der ikke er andet til at differenciere. Et stikord i parentes til at differencere afgørelsen når der er flere afgørelser i samme sag. TorbenTT (diskussion) 25. nov 2017, 16:09 (UTC)
- Din standard lyder fornuftig, det kan være at jeg en gang i mellem vil skulle forhøre mig om hvorvidt en sag har et kaldenavn eller om partsnavnene er meningsfulde, men det går nok :). Ifht. de forskellige tidsskrifter så mener jeg ikke at vi bør bruge dem til navngivning, bla. fordi de kan være nævnt i flere tidsskrifter som du selv nævner. I stedet kan de bruges som nyttige omdirigeringer. F.eks. har jeg gjort så UfR 1989.399 H omdirigerer til Grønjakkesagen. Jeg vil følge din standard fremover. Jeg tænker det er en god ide at oprette en stilmanual på sigt så nye brugere kan have et overblik over navngivning og formatering. InsaneHacker (diskussion) 25. nov 2017, 16:27 (UTC)
- Lige noget opklarende. Skal vi kun bruge denne standard til navngivning af siden, eller skal det også være det der står som titel i Skabelon:Header? InsaneHacker (diskussion) 25. nov 2017, 16:30 (UTC)
- Begge dele tænker jeg, jeg har tidligere givet dem en længere titel i header men det er vel ikke nødvendigt når informationen er i titlen. Hvad synes du? TorbenTT (diskussion) 25. nov 2017, 16:44 (UTC)
- Lige noget opklarende. Skal vi kun bruge denne standard til navngivning af siden, eller skal det også være det der står som titel i Skabelon:Header? InsaneHacker (diskussion) 25. nov 2017, 16:30 (UTC)
- Din standard lyder fornuftig, det kan være at jeg en gang i mellem vil skulle forhøre mig om hvorvidt en sag har et kaldenavn eller om partsnavnene er meningsfulde, men det går nok :). Ifht. de forskellige tidsskrifter så mener jeg ikke at vi bør bruge dem til navngivning, bla. fordi de kan være nævnt i flere tidsskrifter som du selv nævner. I stedet kan de bruges som nyttige omdirigeringer. F.eks. har jeg gjort så UfR 1989.399 H omdirigerer til Grønjakkesagen. Jeg vil følge din standard fremover. Jeg tænker det er en god ide at oprette en stilmanual på sigt så nye brugere kan have et overblik over navngivning og formatering. InsaneHacker (diskussion) 25. nov 2017, 16:27 (UTC)
AdvancedSearch
Birgit Müller (WMDE) 7. maj 2018, 14:44 (UTC)
Update on page issues on mobile web
Update on page issues on mobile web
Hjælp venligst med at oversætte til dit sprog Hi everyone. The Readers web team has recently begun working on exposing issue templates on the mobile website. Currently, details about issues with page content are generally hidden on the mobile website. This leaves readers unaware of the reliability of the pages they are reading. The goal of this project is to improve awareness of particular issues within an article on the mobile web. We will do this by changing the visual styling of page issues.
So far, we have drafted a proposal on the design and implementation of the project. We were also able to run user testing on the proposed designs. The tests so far have positive results. Here is a quick summary of what we learned:
- The new treatment increases awareness of page issues among participants. This is true particularly when they are in a more evaluative/critical mode.
- Page issues make sense to readers and they understand how they work
- Readers care about page issues and consider them important
- Readers had overwhelmingly positive sentiments towards Wikipedia associated with learning about page issues
Our next step would be to start implementing these changes. We wanted to reach out to you for any concerns, thoughts, and suggestions you might have before beginning development. Please visit the project page where we have more information and mockups of how this may look. Please leave feedback on the talk page.
CKoerner (WMF) (talk) 12. jun 2018, 20:58 (UTC)
Bot rights for User:Wikisource-bot
Hi. With the requirement to fix the page categorisation as notified at phab:T198470, I would like to propose to the community to have our bot run through and address the problem with the solution identified. The bot has been used to resolve issue previously on the Wikisources.
Thanks. Billinghurst (diskussion) 7. jul 2018, 08:53 (UTC)
- Sounds good to me. Thanks for looking into this. Peter Alberti (diskussion) 8. jul 2018, 13:30 (UTC)
Addition of daWS to global bots
Above I have added a bot request, as this wiki is not within the global bot project, per list m:Special:WikiSets/2. Would the community consider opting in to the global bots, so that when we have Wikisource-wide fixes for mw:Extension:ProofreadPage that is possible to organise the bots to do the jobs within Phabricator, and simply get the fix in place. Billinghurst (diskussion) 7. jul 2018, 08:54 (UTC)
- Fine by me. Peter Alberti (diskussion) 8. jul 2018, 13:31 (UTC)
Global preferences are available
Global preferences are now available, you can set them by visiting your new global preferences page. Visit mediawiki.org for information on how to use them and leave feedback. -- Keegan (WMF) (talk)
10. jul 2018, 19:19 (UTC)
Consultation on the creation of a separate user group for editing sitewide CSS/JS
(Hjælp venligst med at oversætte til dit sprog)
Hi all,
I'm preparing a change in who can edit sitewide CSS/JS pages. (These are pages like MediaWiki:Common.css and MediaWiki:Vector.js which are executed in the browser of all readers and editors.) Currently all administrators are able to edit these pages, which poses a serious and unnecessary security risk. Soon, a dedicated, smaller user group will take over this task. Your community will be able to decide who belongs in this group, so this should mean very little change for you. You can find out more and provide feedback at the consultation page on Meta. If you are involved in maintaining CSS/JS code, or policymaking around adminship requests, please give it a look!
Thanks!
Tgr (talk) 12. jul 2018, 08:45 (UTC) (via global message delivery)
New user group for editing sitewide CSS/JS
(Hjælp venligst med at oversætte til dit sprog)
Hi all!
To improve the security of our readers and editors, permission handling for CSS/JS pages has changed. (These are pages like MediaWiki:Common.css and MediaWiki:Vector.js which contain code that is executed in the browsers of users of the site.)
A new user group, interface-admin, has been created.
Starting four weeks from now, only members of this group will be able edit CSS/JS pages that they do not own (that is, any page ending with .css or .js that is either in the MediaWiki: namespace or is another user's user subpage).
You can learn more about the motivation behind the change here.
Please add users who need to edit CSS/JS to the new group (this can be done the same way new administrators are added, by stewards or local bureaucrats). This is a dangerous permission; a malicious user or a hacker taking over the account of a careless interface-admin can abuse it in far worse ways than admin permissions could be abused. Please only assign it to users who need it, who are trusted by the community, and who follow common basic password and computer security practices (use strong passwords, do not reuse passwords, use two-factor authentication if possible, do not install software of questionable origin on your machine, use antivirus software if that's a standard thing in your environment).
Thanks!
Tgr (talk) 30. jul 2018, 13:08 (UTC) (via global message delivery)
New user group for editing sitewide CSS / JS
(Hjælp venligst med at oversætte til dit sprog)
Hi all!
To improve the security of our readers and editors, permission handling for CSS/JS pages has changed. (These are pages like MediaWiki:Common.css and MediaWiki:Vector.js which contain code that is executed in the browsers of users of the site.)
A new user group, interface-admin, has been created.
Starting four weeks from now, only members of this group will be able edit CSS/JS pages that they do not own (that is, any page ending with .css or .js that is either in the MediaWiki: namespace or is another user's user subpage).
You can learn more about the motivation behind the change here.
Please add users who need to edit CSS/JS to the new group (this can be done the same way new administrators are added, by stewards or local bureaucrats). This is a dangerous permission; a malicious user or a hacker taking over the account of a careless interface-admin can abuse it in far worse ways than admin permissions could be abused. Please only assign it to users who need it, who are trusted by the community, and who follow common basic password and computer security practices (use strong passwords, do not reuse passwords, use two-factor authentication if possible, do not install software of questionable origin on your machine, use antivirus software if that's a standard thing in your environment).
Thanks!
Tgr (talk) 30. jul 2018, 17:44 (UTC) (via global message delivery)