Wikipedija:Pijaca/Tehnička pitanja – Wikipedija / Википедија
Prijeđi na sadržaj
Izvor: Wikipedija
Wikipedija:Pijaca
Opće teme
Pravila i smjernice
Tehnička pitanja
Jezička pitanja
Novosti
Prečica
WP:P/TEH
WP:P/TEH
Odjeljak Pijace za pitanja, obavijesti, novosti i rasprave povezane s wiki sintaksom, šablonima, modulima,
CSS
-om, botovima, wiki softverom, te ostalim sredstvima Wikipedije koja zahtijevaju određenu tehničku potkovanost.
« Arhive
Započni temu
Questions from the CEE Hub regarding your technical village pump
uredi
uredi kod
Hello and sorry for writing in English. There is an automatically translated version below, feel free to modify it if it contains errors.
I'm user Strainu, member of the
CEE Hub
Steering Committee. One of the directions of the Hub for 2025 is to support its member communities technically, including for technical village pumps. We would like to understand how you use this page, so I would appreciate your answers to a few questions:
If you have a technical problem, does it usually get an answer here?
Does your project have enough technical members to respond such questions?
Are there any profiles missing locally? (for instance: gadget creators, bot creators, people with graphical skills etc.)
On a scale from 1 to 10, how important is it for you to receive an answer in the project's language?
Would you be willing to support smaller communities to resolve technical issues if you get notified about such questions?
Thank you! Based on the community's responses, we will try to provide some ideas that would support you in the next few months. Best,
Strainu
razgovor
10. februara 2025. u 13:22 (CET)
odgovori
Ja sam korisnik Strainu, član
CEE Hub
Upravnog odbora. Jedan od pravaca Huba za 2025. godinu je tehnička podrška njegovim članicama, uključujući tehničke seoske pumpe. Želeli bismo da razumemo kako koristite ovu stranicu, pa bih cenio vaše odgovore na nekoliko pitanja:
Ako imate tehnički problem, da li obično ovde dobijete odgovor?
Da li vaš projekat ima dovoljno tehničkih članova koji mogu odgovoriti na takva pitanja?
Da li nedostaju neki profili na lokalnom nivou? (na primer: kreatori gadžeta, kreatori botova, ljudi sa grafičkim veštinama itd.)
Na skali od 1 do 10, koliko je važno za vas da dobijete odgovor na jeziku projekta?
Da li biste bili voljni da podržite manje zajednice u rešavanju tehničkih problema ako biste bili obavešteni o takvim pitanjima?
Hvala! Na osnovu odgovora zajednice, pokušaćemo da pružimo nekoliko ideja koje bi vas podržale u narednim mesecima. Srdačno,
Strainu
razgovor
10. februara 2025. u 13:22 (CET)
odgovori
Hello @
Strainu
, we sincerely appreciate your commitment to technically support small CEE Hub member communities.
Most issues of technical nature are more likely to get an answer here than in other places on the wiki, unless specifically addressed to another active editor more knowledgeable about the specific issue.
I believe we lack in the number of tech-savvy editors but all questions posed so far have been resolvable relatively easily and quickly.
At the moment, there is only one local and active editor capable of creating technical solutions for the needs of the entire community. We do not have dedicated creators of either gadgets, graphics, or scripts, relying instead on the replicable solutions from larger wikis (sometimes to no avail).
Getting help at all, in any language, takes precedence to not getting any. English is the first foreign language of most editors in our community. Translation tools and LLM are widely accessible on the Internet for others.
Yes. The
m:Cross-Project Collaboration Initiative
was in fact established by several CEE Hub member communities from the region (as an attempt) to strengthen the practice of offering and receiving help, although this project has yet to gain momentum.
Cheers! –
Vipz
razgovor
10. februara 2025. u 17:43 (CET)
odgovori
Sub-referencing: User testing
uredi
uredi kod
Apologies for writing in English, please help us by providing a translation below
Hi I’m Johannes from
Wikimedia Deutschland
's
Technical Wishes team
. We are making great strides with the new
sub-referencing feature
and we’d love to invite you to take part in two activities to help us move this work further:
Try it out and share your feedback
Please try
the updated
wikitext
feature
on the beta wiki
and let us know what you think, either
on our talk page
or by
booking a call
with our UX researcher.
Get a sneak peak and help shape the
Visual Editor
user designs
Help us test the new design prototypes by participating in user sessions –
sign up here to receive an invite
. We're especially hoping to speak with people from underrepresented and diverse groups. If that's you, please consider signing up! No prior or extensive editing experience is required. User sessions will start
May 14th
We plan to bring this feature to Wikimedia wikis later this year. We’ll reach out to wikis for piloting in time for deployments. Creators and maintainers of reference-related tools and templates will be contacted beforehand as well.
Thank you very much for your support and encouragement so far in helping bring this feature to life!
Johannes Richter (WMDE)
talk
28. aprila 2025. u 17:03 (CEST)
odgovori
We will be enabling the new Charts extension on your wiki soon!
uredi
uredi kod
(Apologies for posting in English)
Hi all! We have good news to share regarding the ongoing problem with graphs and charts affecting all wikis that use them.
As you probably know, the
old Graph extension
was disabled in 2023
due to security reasons
. We’ve worked in these two years to find a solution that could replace the old extension, and provide a safer and better solution to users who wanted to showcase graphs and charts in their articles. We therefore developed the
Charts extension
, which will be replacing the old Graph extension and potentially also the
EasyTimeline extension
After successfully deploying the extension on Italian, Swedish, and Hebrew Wikipedia, as well as on MediaWiki.org, as part of a pilot phase, we are now happy to announce that we are moving forward with the next phase of deployment, which will also include your wiki.
The deployment will happen in batches, and will start from
May 6
. Please, consult
our page on MediaWiki.org
to discover when the new Charts extension will be deployed on your wiki. You can also
consult the documentation
about the extension on MediaWiki.org.
If you have questions, need clarifications, or just want to express your opinion about it, please refer to the
project’s talk page on Mediawiki.org
, or ping me directly under this thread. If you encounter issues using Charts once it gets enabled on your wiki, please report it on the
talk page
or at
Phabricator
Thank you in advance! --
User:Sannita (WMF)
talk
6. maja 2025. u 17:07 (CEST)
odgovori
Changes to the way some users are granted the right to see temporary account IP addresses
uredi
uredi kod
Hello! This is the
Trust and Safety Product
team. We would like to share that we have decided to change the requirements for access to temporary account IP addresses.
The impact on your community will be minimal
. We are planning on implementing the change in the week of May 26 (
T393358
T393360
T390942
). I will keep you updated about the details.
We are only changing the rules for users who do not have extended rights (e.g. admins, bureaucrats, checkusers –
see the policy for more examples
) but their account is a minimum of 6 months old, and who have made a minimum of 300 edits on this wiki. They will lose access to IP addresses (
T393360
), and to have it back,
they will need to apply for the right. Admins or stewards will decide whether to grant it
T390942
). This will entail human manual work, but this method will be safer than if we continued to grant the rights automatically. We want to emphasize that fewer than five users who don't have extended rights have ever revealed a temporary account's IP addresses on your wiki.
We made this decision based on what we heard from you, piloting wikis, particularly Romanian Wikipedians. We also consulted on options with Stewards, and had discussions on Meta-Wiki and about 20 Wikipedias with large communities. When we deploy temporary accounts to more wikis, we will evaluate the impact and may adjust our approach again.
In addition, we'd like you to know that requirements for access to the
IP Info
feature will be identical with the ones for access to the temporary accounts' IP addresses (a user will either have full information or none).
The rationale for the change
We chose the current numerical thresholds and automatic granting before deploying temporary accounts on any wiki. However, it’s become clear to us that these requirements are quite low and it is still too easy for bad-faith actors to gain access to temporary account IP addresses. We want temporary accounts to meaningfully improve editor privacy, so we need to be more restrictive. Our goal is to more consistently limit IP address access to only those who need it.
How will this work
When a user without extended rights needs to view temporary account IP addresses, they will need to file a request for being added to the "Temporary account IP viewers" group. They will file the request to admins (the local communities will be able to decide what that process will be) or stewards (for wikis without local admins).
The software will require that the user has at least 300 edits and the account since at least 6 months. Admins and stewards will not be able to grant temporary account IP access to accounts that do not meet that criteria. This is a minimum, and we encourage you to enforce higher thresholds.
The user reviewing the request will check if the user applying for the right meets requirements and that they have provided a valid justification. The right itself will be granted through Special:UserRights.
Users who grant requests for the right will also handle removal of the right.
We would also like to clarify some details. For your convenience, we will also document some of it in
the project FAQ
Access to IP addresses
Separation of the new right
(checkuser-temporary-account) out to a new group (
Temporary account IP viewers
), as opposed to technically attaching it to any
existing group
(like patroller). We have decided to do this for a few reasons:
Having access to IP addresses carries risk
. This right is similar to checkuser. IP addresses are considered personally identifiable information (a kind of
personal data
). Outside actors who want to access IP addresses will now need to interact with users who have this right. Users with this right should be aware of this, and alert to the possibility of suspicious access requests.
Good practices for privacy protection
. Giving access to users who are trusted but do not need access to carry on their work is not in line with good practices for processing personal data.
Removal of right
. Access to IPs will be
logged
example
). If any misuse of this right is detected, it can be taken away separately from any other permissions the user may hold. It would be difficult and sometimes also unreasonable to remove the rights unrelated to access to IP addresses.
You may grant the new right to all users belonging to a certain existing group individually. These users must meet the criteria for Temporary account IP viewers, though.
For clarity – all this does not affect administrators, bureaucrats, checkusers, stewards, and other groups mentioned in the
global policy
Activity requirement
. With regards to users who would need to be granted access manually, the policy says that they "must edit or take a logged action to the local project at least once within a 365-day period". This requirement is not changing.
Process of granting the right
Formality of granting the right
. There is no need for discussions or votes like Request for Adminship. It does suffice if a single admin makes a decision using their own judgement.
Additional requirements for the users applying for the right
You have autonomy over the process for granting the right. You can adopt thresholds higher than 300 edits, or disallow the "non-admin+" users to have the right. The granting process can be as basic or elaborate as you deem appropriate.
Which criteria admins should take when deciding whether to grant the right – how to tell whether a user needs access to IP addresses? There are no mandatory requirements beyond a minimum of 300 edits and a 6 month old account. You may introduce additional criteria related to trust to the user (such as no prior blocks or copyright violations) or experience in patrolling activities.
Additional burden on administrators
. We understand the toil of having to grant and remove an additional right. This is indeed a downside. We think that it will only have to be a one-time effort to grant this right to a larger number of people. We are curious if you can find ways to limit this burden.
Next steps on your side we would like to suggest
We are encouraging you to consider
adopting a policy
on granting and removing the right, if you think you need to add anything to the global policy.
We are encouraging you to
start granting the right
. Considering our data (up to a few non-functionaries have ever revealed temporary account IP addresses here), we believe you don't need to rush or spend a lot of time preparing for this before the change comes into force, though.
We would like to show you what level of wiki-bureaucracy seems sufficient from our point of view.
In the sandbox
, we have created a draft of what a page with requests for the flag could look like. Of course the final content of the page will depend on your community. We do not want to imply that we are instructing you on this matter.
Let us know if you have any questions. Thank you!
NKohli (WMF)
and
SGrabarczuk (WMF)
razgovor
16. maja 2025. u 04:22 (CEST)
odgovori
Join the 6th Wikipedia Pages Wanting Photos Campaign – 2025 Edition
uredi
uredi kod
Dear Wikipedia community,
Please help translate to your language
We invite your community to participate in the 6th edition of the
Wikipedia Pages Wanting Photos Campaign
, a global campaign taking place from July 1 to August 31, 2025.
Participants will choose among Wikipedia pages without photos, then add a suitable photo from among the many thousands of photos in the Wikimedia Commons, especially those uploaded from thematic contests (
Wiki Loves Africa
Wiki Loves Earth
Wiki Loves Folklore
Wiki Loves Monuments
, etc.) over the years.
More than 80 Wikimedia affiliates have participated since the campaign was launched in 2020 and have added images to more than 400,000 Wikipedia articles in over 245 Wikipedia languages. Thanks to the volunteer contributors!
We now invite your community to organize and lead the campaign within your community. As a local organizer, you may:
Encourage individual members to take part by adding images to Wikipedia articles.
Host edit-a-thons focused on improving visual content.
Organize training workshops to teach contributors how to correctly integrate images into Wikipedia.
These activities will help build local capacity and increase visual content across Wikipedia.
Please note that for participants to be eligible to participate in the campaign, they need to have registered an account for at least a year before the official start date of the contest. That is, for the 2025 edition, they must have registered an account on or before July 1, 2025. The account can be from any Wikimedia project wikis.
The organizing team is looking for a contact person to coordinate WPWP participation at the Wikimedia user group or chapter level (geographically or thematically) or for a language Wikipedia.
We would be glad for you to
sign up directly
at
WPWP Participating Communities
With kind regards,
User:Reading Beans
On behalf of the Wikipedia Pages Wanting Photos campaign 2025.
MediaWiki message delivery
razgovor
18. maja 2025. u 23:53 (CEST)
odgovori
Poboljšanje jezičkih fallbackova
uredi
uredi kod
Uvedeno
Zaključci navedeni na dnu. –
Aca
razgovor
11. jula 2025. u 20:09 (CEST)
odgovori
Donja rasprava je zaključena.
Nemojte je mijenjati.
Naknadne komentare ostavljajte u novom odjeljku ove stranice ili na odgovarajućoj stranici za razgovor.
Na prijedlog Međuprojektne saradnje, donosim nekoliko ideja za poboljšanje jezičkih fallbackova unutar interfejsa.
Za glavni srpskohrvatski kod:
sh (trenutno):
$fallback = 'sh-latn, sh-cyrl, bs, sr-el, sr-latn, hr';
sh (predloženo):
$fallback = 'sh-latn, bs, cnr-latn, cnr, hr, sr-latn, sr-el, cnr-cyrl, sh-cyrl, sr, sr-cyrl, sr-ec';
Za srpskohrvatski latinični kod treba proširiti fallbackove (tako da idu prvo latinični ijekavski, pa ćirilični):
sh-latn (trenutno):
$fallback = 'sh, sh-cyrl, bs, sr-el, sr-latn, hr';
sh-latn (predloženo):
$fallback = 'sh, bs, cnr-latn, cnr, hr, sr-latn, sr-el, cnr-cyrl, sh-cyrl, sr, sr-cyrl, sr-ec';
Za srpskohrvatski ćirilični kod treba proširiti fallbackove (tako da prvo idu ćirilični pa latinični):
sh-cyrl (trenutno):
$fallback = 'sr-cyrl, sr-ec, sh-latn';
sh-cyrl (predloženo):
$fallback = 'sr-cyrl, sr-ec, sr, cnr-cyrl, sr-latn, sr-el, sh, sh-latn, bs, cnr, cnr-latn, hr';
U ime Međuprojektne saradnje,
Aca
razgovor
30. juna 2025. u 03:42 (CEST)
odgovori
Prijedlog je još u izradi/pripremi. –
Aca
razgovor
30. juna 2025. u 12:39 (CEST)
odgovori
Prijedlog je sada spreman. –
Aca
razgovor
30. juna 2025. u 17:14 (CEST)
odgovori
Samo da specificiram, fallbackovi su rezervni jezici koji se upotrebljavaju u slučaju da neka poruka interfejsa nije prevedena na srpskohrvatski jezički kod. Dakle, da uzmemo primjer sh-cyrl, ako poruka nije prevedena na srpskihrvatsku ćirilicu, uzima se prijevod iz srpske ćirilice; ako prijevoda nema u srpskoj ćirilici, onda se uzima prijevod iz crnogorske ćirilice itd. Nadam se da je sada jasnije kako ovo radi. –
Aca
razgovor
1. jula 2025. u 08:04 (CEST)
odgovori
Budući da nema protivljenja, zaključujem da postoji konsenzus za poboljšanje jezičkih fallbackova. Bit će napravljen task na Phabricatoru i zakrpa na Gerritu. –
Aca
razgovor
9. jula 2025. u 21:56 (CEST)
odgovori
Ovo se ipak mora reducirati na 8 jezičkih kodova, s obzirom na tehnička ograničenja. –
Aca
razgovor
10. jula 2025. u 01:45 (CEST)
odgovori
Uvedeno, zbog tehničkih ograničenja izostavljeni su sledeći kodovi:
cnr-cyrl
cnr-latn
cnr
sr
. –
Aca
razgovor
10. jula 2025. u 10:53 (CEST)
odgovori
Gornja rasprava je zaključena.
Nemojte je mijenjati.
Naknadne komentare ostavljajte u novom odjeljku ove stranice ili na odgovarajućoj stranici za razgovor.
Poboljšanje transwiki uvoza
uredi
uredi kod
Uvedeno
Zaključci navedeni na dnu. –
Aca
razgovor
11. jula 2025. u 19:56 (CEST)
odgovori
Donja rasprava je zaključena.
Nemojte je mijenjati.
Naknadne komentare ostavljajte u novom odjeljku ove stranice ili na odgovarajućoj stranici za razgovor.
Na inicijativu Međuprojektne saradnje, predlažem omogućavanje transwiki uvoza sa sledećih Wikipedija:
bs
hr
sr
U ime Međuprojektne saradnje,
Aca
razgovor
30. juna 2025. u 03:51 (CEST)
odgovori
Za
, podržavam.–
Inokosni organ
razgovor
30. juna 2025. u 23:08 (CEST)
odgovori
Na temelju provedene rasprave zaključujem da postoji konsenzus za uvođenje transwiki uvoza sa bswikija, hrwikija i srwikija. Izrađen je
odgovarajući task na Phabricatoru
. –
Aca
razgovor
9. jula 2025. u 21:03 (CEST)
odgovori
Uvedeno. –
Aca
razgovor
10. jula 2025. u 10:54 (CEST)
odgovori
Gornja rasprava je zaključena.
Nemojte je mijenjati.
Naknadne komentare ostavljajte u novom odjeljku ove stranice ili na odgovarajućoj stranici za razgovor.
Wikidata Item and Property labels soon displayed in Wiki Watchlist/Recent Changes
uredi
uredi kod
(Apologies for posting in English, you can help by translating into your language)
Hello everyone, the
Wikidata For Wikimedia Projects
team is excited to announce an upcoming change in how Wikidata edit changelogs are displayed in your
Watchlists
and
Recent Changes
lists. If an edit is made on Wikidata that affects a page in another Wikimedia Project, the changelog will contain some information about the nature of the edit. This can include a QID (or Q-number), a PID (or P-number) and a value (which can be text, numbers, dates, or also QID or PID’s). Confused by these terms? See the
Wikidata:Glossary
for further explanations.
The upcoming change is scheduled for
17.07.2025
, between
1300 - 1500 UTC
The change will display the label (item name) alongside any QID or PIDs, as seen in the image below:
These changes will only be visible if you have Wikidata edits enabled in your User Preferences for Watchlists and Recent Changes, or have the active filter ‘Wikidata edits’ checkbox toggled on, directly on the Watchlist and Recent Changes pages.
Your bot and gadget may be affected! There are thousands of bots, gadgets and user-scripts and whilst we have researched potential effects to many of them, we cannot guarantee there won’t be some that are broken or affected by this change.
Further information and context about this change, including how your bot may be affected can be found on this
project task page
. We welcome your questions and feedback, please write to us on this dedicated
Talk page
Thank you, -
Danny Benjafield (WMDE)
on behalf of the Wikidata For Wikimedia Projects Team.
MediaWiki message delivery
razgovor
14. jula 2025. u 14:45 (CEST)
odgovori
Šabloni:tko, kojem, što, kada, gdje, zašto, kako
uredi
uredi kod
Imamo glavne šablone za provjeru točnosti informacija u sadržaju članka. Nalaze se u kategoriji
Šabloni za citiranje i sporove provjerljivosti
. Ako imate još šablona za predložiti, slobodno dodajte.–
Inokosni organ
razgovor
18. jula 2025. u 17:23 (CEST)
odgovori
Odlično. Uključi te šablone na bar jednoj stranici, da ne bi zatrpavale
izveštaje održavanja
. –
Aca
razgovor
18. jula 2025. u 17:35 (CEST)
odgovori
Njih bi bilo preporučljivo koristiti što više, naravno pri patroliranju. Na primjer, nisam dužan brisati ili forsirano gledati kroz prste informaciji koja je sumnjiva, ali zato mogu postaviti upit i ukazati na njezinu nestabilnost. –
Inokosni organ
razgovor
18. jula 2025. u 19:09 (CEST)
odgovori
Naravno, podrazumijeva se. Moja gornja napomena odnosila se na to da svaki šablon treba imati bar 1 uključenje, pa makar i samo na vlastitoj dokumentacijskoj stranici, kako ne bismo opterećivali izvještaje. :) –
Aca
razgovor
18. jula 2025. u 19:11 (CEST)
odgovori
Da, naravno, to ćemo brzo.
Imam dodatno pitanje tj. napravio bih i sljedeće dodatne šablone:
Neprovjerljiva hipoteza
Vrlo sumnjivo
Neneutralno stajalište
Nelogično
Neprecizno
Ali nisam siguran, jer ako dublje pogledamo, oni upućuju na provjeravanja koja su već uključena u šablonima tko, kojem, što, kada, gdje, zašto, kako. Možda samo se dodaju neke suptilnosti: "neprovjerljiva hipoteza" ili "neprovjerljivo", znači ne samo da nema izvora, nego za dotične činjenice nema mogućih dokaza; "vrlo sumnjivo" bi bio generičan šablon (što po sebi nije naj naj); "neneutralno stajalište" bi bila
inline
verzija postojećeg šablona
NPOV
, tako da u sadržaju mogu točno ukazati gdje stoji neneutralna izjava; ostala dva šablona bi bila također generična. Što mislite vi o ovome? –
Inokosni organ
razgovor
18. jula 2025. u 19:29 (CEST)
odgovori
Ako
za dotične činjenice nema mogućih dokaza
, onda takva činjenica ne treba ni biti u članku. Šablon tu nema upotrebnu vrednost. Vrlo sumljivo mi je vrlo sumljivo. Za neneutralnu tvrdnju se slažem – to treba napraviti (v.
neutralnost osporena
). Ostala dva šablona su mi neprecizna. :) –
Aca
razgovor
18. jula 2025. u 19:36 (CEST)
odgovori
Sjajno. @
Aca
Možemo li ga nazvati "neneutralno", radi jednostavnosti? –
Inokosni organ
razgovor
18. jula 2025. u 19:42 (CEST)
odgovori
Može,
less is more
, možda radije "pristrano"? –
Aca
razgovor
18. jula 2025. u 20:04 (CEST)
odgovori
Mislim da nam za sada ne treba toga toliko. "Nelogično" je nepotrebno jer je to vrijednosni sud sam po sebi; nelogične rečenice treba uklanjati, a ne ih ostavljati - plus, nije svakome sve isto logično, a ako baš piše da "RIbe plivaju u vodi dok trče kopnom", onda tu ne treba šablon, nego brisanje. "Vrlo sumnjivo" je neenciklopedijski i te izjave isto treba uklanjati ili staviti
{{
fact
}}
uz obrazloženje. "Neprecizno" je okej, ali nisam siguran koliko nam treba. "Neprovjerljiva hipoteza" je nešto za naučnike - mi to nismo. Ja ne mogu procijeniti je li nekakva hipoteza provjerljiva ili ne jer nemam dovoljno stručnih znanja za to. "Neneutralno stajalište" nam ne treba iz dva razloga. Prvo, imamo
{{
NPOV
}}
, a drugo - dogovoreno je odavno da članci ne imaju sadržavati vrijednosne sudove ili stajališta. Dakle, jedino možda "neprecizno", ali mislim da nam ni to
trenutno
ne treba. Za to bismo morali prvo imati neku stilsku smjernicu o tome što je precizno, a što ne. –
Edgar A.
Poe
19. jula 2025. u 03:19 (CEST)
odgovori
Okej, onda da izbrišem šablon "neneutralno" (Edgar) ili da ga "preimenujem" (Aca)?
Što se tiče smjernice, ide na moju listu "stvari za uraditi". –
Inokosni organ
razgovor
21. jula 2025. u 19:15 (CEST)
odgovori
Sredio sam ja to. –
Edgar A.
Poe
21. jula 2025. u 19:25 (CEST)
odgovori
Edgar Allan Poe
Inokosni organ
: Možda je bolje da taj šablon vratimo i preimenujemo. Bilo bi super da možemo
inline
označavati sporne tvrdnje, što je svrha šablona. Šablon POV služi za označavanje celog članka, a ovaj šablon koristio bi se za konkretne rečenice. Zadnjih nekoliko dana sređivao sam članke s pristranim formulacijama, gde su problematične bile samo pojedine rečenice, ali ne i celi članak. Zato mislim da šablon ima svrhu i da ga treba vratiti. –
Aca
razgovor
21. jula 2025. u 19:39 (CEST)
odgovori
Jedna rečenica se treba riješiti na mjestu, a ne ostavljati. Ukoliko je sistemski, onda ima opći šablon, koji može ići i za sekciju, a ne cijeli članak. Svrha ovih šablona je da popune praznine koje postoje kod većih šablona, a ne da dupliciraju istu svrhu. –
Edgar A.
Poe
22. jula 2025. u 02:46 (CEST)
odgovori
Edgar Allan Poe
: Po toj logici ne bi trebalo da postoji nijedan
inline
šablon (
[j]edna rečenica se treba riješiti na mjestu
). Možda neko ne zna kako treba srediti rečenicu u skladu sa enciklopedijskim stilom i rađe bi je samo označio za sređivanje, nego da sam čeprka. Nadalje, možda nije jedna rečenica, nego celi pasus. Šablon se može i tu koristiti. Označavanje celog članka može biti neprecizno i nejasno, pogotovo ako je on dugačak.
Inline
šabloni služe da konkretno specificiraju i lokaliziraju veće šablone, što bi bio i ovde slučaj. –
Aca
razgovor
22. jula 2025. u 02:55 (CEST)
odgovori
Kako ne? Koji drugi šablon koi imamo pokriva pitanje - tko, što, koji, čiji, gdje? Nijedan. Koji pokriva - potrebna provjera izvora ili neuspjela provjera izvora? Nijedan. Nije poanta da je inline šablon sam po sebi sporan, nego da je ovo već pokriveno. Za konkretizaciju postoji SRZ članka. –
Edgar A.
Poe
22. jula 2025. u 02:58 (CEST)
odgovori
Edgar Allan Poe
: Ta logika nema smisla. Imamo i
{{
Nedostaje referenca
}}
, uprkos činjenici da postoji
{{
Nedostaju izvori
}}
. Potpuno ista svrha, razlike nema. –
Aca
razgovor
22. jula 2025. u 03:01 (CEST)
odgovori
Je, samo što neutralnost jedne rečenice nije nešto što bi se trebalo rješavati na taj način. Ako u nekoj rečinici piše "Brad Pitt je najljepši muškarac u povijesti", onda se to ispravi, a ne piše da je ta jedna rečenica neobjektivna - tako se samo gomilaju "problemski" članci, a radi se o minornim problemima koje nema potrebe gomilati. Ova dva citirana šablona su drugo - drugi se uglavnom koristi kada izvora uopće nema ili ih je nedovoljno, što je značajan sustavni problem (kao i NPOV članka), a ovo je za pojedinačne tvrdnje koje nisu sustavne. Međutim, pronaći izvor puno je složeniji proces od ispravljanja jedne neneutralne rečenice. –
Edgar A.
Poe
22. jula 2025. u 03:20 (CEST)
odgovori
Mhm, okej. Slažem se onda. –
Aca
razgovor
22. jula 2025. u 03:32 (CEST)
odgovori
Kategorije:Dinastije
uredi
uredi kod
Poštovane kolege,
Na temelju prijedloga jednog kolege postavio sam si pitanje o tome kako postupamo s kategorijama koje se odnose na dinastije. Čini mi se da se o tome već govorilo na Pijaci, kada se raspravljalo o imenima papa i kraljeva, ako se ne varam. U svakom slučaju, ovdje imamo
kategoriju Rjurikovići
kategoriju Dinastija Rjurikovič
. Kako ih razvrstavamo – s oznakom "dinastija" ili bez nje? Drugo: imena dinastija, transliteriramo li ih (Rjuriković) ili ih ostavljamo onako kako su zapisani u izvorniku (Rjurikovič)? Hvala. –
Inokosni organ
razgovor
15. oktobra 2025. u 23:39 (CEST)
odgovori
Mislim da je format "Dinastija [IME]" najpraktičniji jer dokida problem nedosljednosti. Kako ćemo Saxe-Coburg-Gotha? Sakeskoburggotovići? :D Ovako, ako je sve "Dinastija [Ime]", onda smo mirni i sve će biti potpuno dosljedno. Isto vrijedi i za zadržavanje izvornog imena dinastije; to je dosljedno praksi i jezičnim smjernicama koje imamo. –
Edgar A.
Poe
16. oktobra 2025. u 02:03 (CEST)
odgovori
+1 za "Dinastija Rjurikovič", per Edgar. –
Aca
razgovor
16. oktobra 2025. u 13:32 (CEST)
odgovori
Da, i ja se slažem s opcijom "Dinastija Rjurikovič". Slijedi pitanje: hoćemo li dakle sve dinastijske kategorije (i članke) preimenovati prema tome principu? –
Inokosni organ
razgovor
17. oktobra 2025. u 01:44 (CEST)
odgovori
Da, dosljednosti radi –
Edgar A.
Poe
17. oktobra 2025. u 03:28 (CEST)
odgovori
Inokosni organ
Edgar Allan Poe
: Usklađeno za Dinastiju Rjurikovič. –
Aca
razgovor
29. marta 2026. u 17:22 (CEST)
odgovori
Aca
: sjajno!–
Inokosni organ
razgovor
30. marta 2026. u 15:51 (CEST)
odgovori
Funding tech projects
uredi
uredi kod
Hi everyone,
The
CEE Hub Technical Advancement working group
is organising an open call to support software development projects related to Wikimedia.
We invite individuals, groups, and affiliates to apply with their tech project ideas. Selected projects will receive funding support.
To apply, please send your proposal by
January 25, 2026
to: toni.ristovski@wmceehub.org
For full details, including eligibility and criteria, please read the
announcement
on our Meta page
Feel free to reach out if you have any questions. –
MHeidarzadeh-CEEhub
razgovor
20. januara 2026. u 15:50 (CET)
odgovori
Tipografska standardizacija šablona Jez-x
uredi
uredi kod
Usvojeno
Postoji konsenzus za ispis stranog teksta na ćirilici i latinici u jezičnim šablonima u kurzivu.
Postoji konsenzus za ispis stranog teksta na drugim pismima običnim slovima.
Aca
razgovor
20. marta 2026. u 00:14 (CET)
odgovori
Donja rasprava je zaključena.
Nemojte je mijenjati.
Naknadne komentare ostavljajte u novom odjeljku ove stranice ili na odgovarajućoj stranici za razgovor.
Trenutno neki
šabloni Jez-x
koriste kurziv, a neki obična slova. Dosad smo sledili praksu s enwikija koja je nalagala da se tekst na latiničnim stranim jezicima piše u kurzivu, a tekst na ćiriličnim običnim slovima. Tako imamo
Šablon:Jez-en
koji ispisuje kurzivni tekst i
Šablon:Jez-ru
koji ispisuje obična slova. Ovo rešenje nije optimalno iz sledećih razloga:
U ćiriličnoj verziji članaka (putem Jezičkog konvertora) ćirilični strani tekst nema nikakvu kurzivnu označenost, odudarajući od latiničnog konteksta.
Ćirilični zapis nekad treba da bude ukošen, pogotovo za nazive umetničkih dela.
Međutim, tu se postavljaju nova pitanja:
Nazivi dela na stranom jeziku koji se služi latinicom takođe trebaju biti iskošeni. Trenutno nema nikakve razlike u tipografiji između nasumične strane reči poput
computer
i naziva dela poput
Romeo and Juliet
. Zašto se uopšte koristi kurziv ako nam je već naznačen naziv jezika?
Kolega
Vipz
izneo je sledeće ideje za tipografsku standardizaciju na Discordu:
Ne treba stavljati u kurziv nijedan strani naziv koji se u jeziku izvorniku ne piše u kurzivu.
Ne treba stavljati podebljanje ni na jedan strani naziv u zagradama kako bi se izbjegla preterana upotreba podebljanja u prvoj rečenici članka.
Tekst na drugim pismima nikad ne treba stavljati u kurziv, osim srpskohrvatske ćirilice koja će se automatski prikazati u kurzivu kroz transliterator.
Vipz je naveo Nirnberg kao adekvatan primer varijantske ujednačenosti:
Nürnberg
(izgovor: Nirnberg) je [...]
Nürnberg
je
Nirnberg
(njemački: Nürnberg) je [...]
Nirnberg
je
Ja bih ovde dodao da se ćirilca može italicizirati za nazive dela, kao u
Zločin i kazna
Ovi predlozi su dosta velika promena dosadašnje prakse, pa bi bilo poželjno videti širi stav zajednice i koliko je sve ovo izvodljivo.
Moj prvobitni predlog je bio da se ćirilica italicizira i da se time latinični i ćirilični konteksti izjenače. Ideja je prosta i konkretna, ali ne ulazi u suštinu drugih povezanih pitanja. Unapred zahvalan na komentarima. –
Aca
razgovor
12. marta 2026. u 02:02 (CET)
odgovori
Moj kontrapredlog: Budući da jezički šaboni govore o terminima kao takvima, predlažem kodifikaciju prakse sa ruwikija:
Ćirilički i latinički zapisi na stranom jeziku u jezičkim šalonima pišu se uvek kurzivom, nezavisno o kom je terminu reč.
Ostali zapisi na drugim pismima pišu se bez kurziva, jer većina drugih pisama i ne podržava kurziv.
Aca
razgovor
12. marta 2026. u 03:26 (CET)
odgovori
Glede kako su i latinica i ćirilica naša pisma, ja sam za stavljanje i latiničnih i ćiriličnih naziva u nakošen tekst, a sad ostala, nama strana pisma se ne moraju stavljati. –
Fertile Snowcent
razgovor
12. marta 2026. u 07:04 (CET)
odgovori
Ovo je puno komplicirano za stvar koja je suštinski čisto stilska odluka koja se u nekom kasnijem trenutku može lako promijeniti. Svi argumenti imaju smisla, s tim da se slažem s dosad izrečenim da nećirilična-nelatinična strana pisma trebaju ostati kako jesu, dakle bez kurziva. Ostalo, podržavam opciju koja je najlakša za provesti u tehničkom smislu jer mislim da neće kvaliteta projekta opasti ako piše "Nürnberg" ili
Nürnberg
. –
Edgar A.
Poe
12. marta 2026. u 15:04 (CET)
odgovori
Типографија је далеко мање важна, од непоштовања срБског језика у целини. Нема екавице, нема срБских речи... Превођење хрватског на срБски, изостаје... У суштини, ћирилично писмо, које ви овде користите, није српски језик, него непостојећи хрватски, исписан ћирилицом. –
~2026-16512-01
razgovor
16. marta 2026. u 08:41 (CET)
odgovori
Dragi korisniče, hvala vam na komentaru, uzeću slobodu da ga shvatim ozbiljno. Mislim da vaša kritika – iz vašeg ugla – je na mestu, ali iz našeg ona se uklapa u dugačak niz primedbi koje smo tokom godina dobijali, a koje imaju za cilj da dovedu u pitanje samu legitimnost srpskohrvatskog jezika. Vaša mi, dakle, deluje kao legitimna opservacija, dok je u toj nepreglednoj seriji sličnih kritika najčešće bila reč o pravim napadima, ponekad iznenađujuće žestokim. Bilo je ljudi koji su iz tog razloga pokretali zahteve za zatvaranje čitavog našeg projekta. Te zahteve smo, razume se, uredno vratili pošiljaocu pa danas na to više i ne trošimo mnogo vremena: ako korisnik napadne projekat na osnovu jezika, mi ga jednostavno blokiramo i pozovemo da svoju finu retoriku i nacionalnu lingvistiku praktikuje tamo gde će biti bolje shvaćen.
S naše strane, ostajemo Vikipedija na srpskohrvatskom jeziku, polazimo od načela policentričnosti jezika te nastojimo da očuvamo koegzistenciju različitih varijanti istog jezika. Lično se trudim da osiguram pluralitet glasova, ali vas uveravam da moje kolege čine isto — a možda i bolje od mene.
Odgovoriću direktno na vašu poruku. Pođimo od upotrebe jezika: vaša poruka je napisana ćirilicom, ali pišete "срБског језика", dok je pravilno "српског језика". Kažete "Нема екавице, нема срБских речи": jeste li sigurni u to? Imamo, na primer, članke
Ludwig Wittgenstein
ili
Vlajko Begović
, izabrali smo ih za članke od vrednosti i preporučujem vam da ih pročitate. Kažete: "Превођење хрватског на срБски изостаје". Mi ne prevodimo iz jedne varijante u drugu. Nikako i nipošto! Iz kog razloga bi jedan Austrijanac prevodio
Hajnovu
pesmu sa nemačkog na austrijski? Ako on ne razume tekst Heinea, onda Heine nije stranac — već jednostavno on nije pročitao dovoljno knjigâ na svome sopstvenom jeziku. Po mom mišljenju, ako govorite srpski, trebalo bi da vam bude sasvim prirodno da čitate i Krležu i Daviča, i to bez ikakvog napora. Uz to, opšte pravilo kod nas jeste da članak prati onu jezičku varijantu koja dominira u njegovom tekstu. Ako ste, recimo, napisali deset hiljada reči u standardu kakav se govori i piše u Nišu, a drugi korisnik je dodao dvesta u varijanti kakva se koristi u Umagu, onda će se prilikom generalnog pregleda (na kraju, inače) tekst u pravilu uskladiti sa niškom varijantom. Ali pojmovi i sadržaj moraju ostati tačno onakvi kakvi jesu — bez obzira na jezičku varijantu. Lep pozdrav –
Inokosni organ
razgovor
16. marta 2026. u 18:16 (CET)
odgovori
Saglasan sam s Inokosnim organom ovde. Dapače/štaviše, većina članaka na ovoj jezičkoj verziji Wikipedije napisana je, igrom slučaja, na srpskoj varijanti ekavskog izgovora (botovski unosi), i kao takvi to su legitimni članci jednakog statusa na ovome projektu, što je regulirano usvajanjem
jezičkih smernica
. Što se tiče ispravne transkripcije stranih reči, to je pitanje na kojem ova zajednica aktivno radi i razmatra sve moguće solucije kako da Jezički konvertor radi najbolji mogući posao. U tom pogledu, mislim da ovaj projekat nastoji očuvati sve raznolikosti našeg jezika, ali da istovremeno ostane praktičan i upotrebljiv. Ipak, svaka pomoć u poboljšanju kvaliteta Jezičkog konvertora je dobrodošla, pa sam zato urgirao da ovaj komentar bude shvaćen dobronamerno i da imamo što širu paletu mišljenja kako bismo ostvarili naš cilj ravnopravnosti svih standardnih varijeteta. –
Aca
razgovor
17. marta 2026. u 00:45 (CET)
odgovori
Gornja rasprava je zaključena.
Nemojte je mijenjati.
Naknadne komentare ostavljajte u novom odjeljku ove stranice ili na odgovarajućoj stranici za razgovor.
Request for Comment: VisualEditor automatic reference names
uredi
uredi kod
Hi, I’m Johannes from
Wikimedia Deutschland
’s
Technical Wishes team
. Apologies for writing in English. Pomozite pri prevođenju na Vaš jezik! We are considering to work on
Community Wishlist/W17: Improve VE references' automatic names and reuse
. This has been a long-term issue for wikitext editors (see e.g.
en:WP:VisualEditor/Named references
) which has been among the top-voted wishes in several
Community Wishlist Surveys
, e.g.
2017
2019
2022
or
2023
We would like your input on the
solutions
proposed on our project page:
m:WMDE Technical Wishes/References/VisualEditor automatic reference names
. We are considering several options, which can be combined if desired by the community.
Changing the default pattern for automatically generated reference names (currently
":n"
, e.g.
":0"
":1"
...) to use the
reference type
instead (e.g.
"book_reference-1"
).
Providing a simple mechanism for communities to configure a different default name.
Generating automatic reference names based on the
domain name
(if it’s a web citation).
Generating automatic reference names based on template parameters (e.g. "title" or "last"+"first") – defined by the community.
Feedback
uredi
uredi kod
Visit our project page
to read about our proposal in detail and share your thoughts
on metawiki
Please note
: We will only implement a solution if there’s clear consensus among the global community. Our intention is not to build the perfect solution, but to find a simple and lean one that alleviates the pain caused by auto generated names. We are aware that some experienced VisualEditor users might prefer an option to manually change reference names in VisualEditor, but such a UX intervention is difficult to achieve across reference types and thus out of scope for our team, we can only improve the auto-naming mechanism.
We are happy about suggestions for improving certain details of the proposed solutions. Any other feedback and alternative proposals are also welcome – even though it’s out of scope for us, it might still be relevant for future work on this topic.
Please support us interpreting consensus by clearly indicating your opinion (e.g. by using support/neutral/oppose templates). We are aware of
en:WP:NOTVOTE
, but given that we are facilitating this discussion with users from different wikis, potentially commenting in their native language, clearly indicating your position helps us avoid misunderstandings.
Thank you for participating!
Johannes Richter (WMDE)
razgovor
19. marta 2026. u 12:15 (CET)
odgovori
Action Required: Update templates/modules for electoral maps (Migrating from P1846 to P14226)
uredi
uredi kod
Hello everyone,
This is a notice regarding an ongoing data migration on Wikidata that may affect your election-related templates and Lua modules (such as
Module:Itemgroup/list
).
The Change:
Currently, many templates pull electoral maps from Wikidata using the property
P1846
, combined with the qualifier
P180
Q19571328
We are migrating this data (across roughly 4,000 items) to a newly created, dedicated property:
P14226
What You Need To Do:
To ensure your templates and infoboxes do not break or lose their maps, please update your local code to fetch data from
P14226
instead of the old
P1846
P180
structure. A
list of pages
was generated using Wikimedia Global Search.
Deadline:
We are temporarily retaining the old data on
P1846
to allow for a smooth transition. However, to complete the data cleanup on Wikidata, the old
P1846
statements will be removed after
May 1, 2026
. Please update your modules and templates before this date to prevent any disruption to your wiki's election articles.
Let us know if you have any questions or need assistance with the query logic. Thank you for your help!
ZI Jony
using
MediaWiki message delivery
razgovor
3. aprila 2026. u 19:09 (CEST)
odgovori
Nemamo što uraditi povodom ovoga. Jedini shwiki šablon na popisu stranica koju su generisali je
Šablon:PBB/2065
, a on ne koristi svojstva Wikipodataka. –
Vipz
razgovor
3. aprila 2026. u 19:18 (CEST)
odgovori
Izvor:
Kategorija
Wikipedijina Pijaca
Wikipedija
Pijaca/Tehnička pitanja
Započni temu