Finally, I found some time to continue with work on the project Mass
content adding (http://meta.wikimedia.org/wiki/Mass_content_adding). I
started with preparing materials for adding countries
(http://meta.wikimedia.org/wiki/Countries_of_the_world and
http://meta.wikimedia.org/wiki/Countries_of_the_world/Names_of_the_countries)
and I found a number of open questions of multilingual/cross-Wikipedia
cooperation.
As I want to have the base for countries related things -- on English
Wikipedia -- the first point on the road of getting some help was the
WikiProject Countries
(http://en.wikipedia.org/wiki/Wikipedia:WikiProject_Countries) on
English Wikipedia. I wrote a message to the participants of the
project and I am waiting for their response...
And, here is the point: It is very useful for me that some other
projects can cover some parts of the project Mass content adding. But,
this is the project of English Wikipedia, not a multilingual project.
And I am sure that some people from other Wikipedias would be
interested to participate in the project Mass content adding. Also,
for the MCA project, there is a need for coordination between a number
of Wikipedian communities. And there is no such thing as "Coordination
place for WikiProjects Countries". And this is just one example of
need for cross-Wikipedia coordination/cooperation.
So, I think that all of such projects should have some place on Meta
for multilingual coordination. This means, also, that there people
from different Wikipedias should announce the existance of new project
on some page on Meta.
I would like to see a unified template for countries on all of
Wikipedias; a unified template for biographies on all of Wikipedias;
etc. In general, smaller Wikipedias are copying English templates, but
there are no feed-backs.
I remember: when I asked people on Serbian Wikipedia would we want to
use a template from English Wikipedia, one of them said "Why to use
their, our is better?" And, in deed, in that time Infobox Country on
Serbian Wikipedia was based on Infobox Country on English Wikipedia,
but with some more features.
In other words, I think that a number of technical details on
Wikipedia should be multilingual and not specific for the local
Wikipedias.
Clarifying this idea in the light of responses, and further suggestions:
As this is a button beneath the edit box it would have to be fully, properly
written into the PHP that is MediaWiki - i.e. this function would arrive
with a new version of the software. So small additions to the framework that
make it work seem okay to me.
The button only appears for a logged in user. When you click it, the page
saves to "User:Example/Pagename" rather than "Pagename".
To streamline this Drafts system, it could also then save into the user
subpage a magic word like "__DRAFT__" which, on any page, forces the
appearance of a new tab/toolbox option like "Finalise".
Clicking Finalise is then equivalent to having done all three of these at
once:
* Editing the original page
* Pasting the new drafted text into the edit box
* Clicking "Show changes" to display a diff
In the absence of this "Finalise" button and/or "__DRAFT__" magic word, the
original "Save Draft" button could simply prepend the saved user subpage
with automatic links to edit and diff the original article (with exact text
specified in a System Message).
Or in the simplest incarnation, "Save Draft" just saves to a user subpage
and that's it.
Whatever the case, this function would be infinitely useful because edits
are often longer than a single session, but not necessarily longer than the
time between revisions of an article. It would simply automate what a lot of
people already do anyway (i.e. end up working offline), and would encourage
more high-quality focused work on articles.
According to [1] stamps from Ukraine are in the public domain. This
would follow from the following two clauses from respectively the
Ukrainian Copyright Law [2] and Postal Law [3]:
> (d) State symbols of Ukraine, government awards; symbols and signs of
> government authorities, the Armed Forces of Ukraine and other
> military formations; symbols of territorial communities; symbols and
> signs of enterprises, institutions and organizations;
> postage stamp - a state sign, manufactured according to the procedure
> set forth by legislation, with specified face value and state,
> serving as the tool of payment for postal services provided by the
> national operator.
The Russian Copright [4] and Postal [5] laws include similar clauses:
> Article 8. Works Not Protected by Copyright
>
> The following are not protected by copyright:
>
> official documents (laws, court decisions, other texts of
> legislative, administrative or judicial character) and official
> translations thereof; State emblems and official signs (flags,
> armorial bearings, decorations, monetary signs and other State
> symbols and official signs); works of folklore; communications
> concerning events and facts that have informational character.
> the state signs of post payment - post stamps and other signs,
> applied to the post sendings and those confirming the payment of
> services to postal communication;
[1]http://commons.wikimedia.org/wiki/Stamps/Public_domain
[2]http://en.wikisource.org/wiki/Ukraine._Law_on_Copyright_and_Related_Rights
[3]http://www.welcometo.kiev.ua/pls/ili/docs/LAW_ENG/EQ2759-III_28-05-03.HTML
[4]http://en.wikisource.org/wiki/Russian_Federation._Law_on_Copyright_and_Ne…
[5]http://www.russianpost.ru/resp_engine.aspx?Path=RU/Home/law/postlaw
Would it be correct to conclude that Russian stamps are in the public
domain as well?
Ruud
Recently I have a problem accessing to Thai Wikipedia (
http://th.wikipedia.org). It froze many times with blank white pages with no
any single HTML code when I viewed the source. I need to reload two or three
times before the text came out. I also wrote on the Village Pump in Thai WP
several days ago, but seems no one has discussed about this problem yet.
I'm using both Firefox 1.5.0.6 and IE 7 beta 2 on Windows XP SP 2.
Best regards,
Manop (Thai Wikipedia)
Users would accept the fact that edit conflicts might arise. I accept it
anyway when I'm making a large edit (e.g. a massive article expansion) and
for those users who edit offline (there are many), they certainly accept it
too. I think the point here is that, people make huge edits anyway, and this
would only make it easier. Especially if a "Finalise" feature could also be
implemented in the draft page.
If this could be implemented now, using JavaScript, I would like to see that
(I'd certainly use it). It would possibly be better as opt-in anyway.
Another function this would provide is something like a manual AutoSave. If
you're making a large edit the last thing you want to happen is for your
browser to crash and lose it all (and yes I even use Firefox :P). It would
be reassuring to be able to "Save" the page in progress without having to
wait till you're completely done, and without disrupting the actual article.
Dear all,
Wikimania 2006 just closed its doors a week or so ago, and it is
already time to think about the next edition.
As happened in 2005 and 2006, the city hosting Wikimania in 2007 will
be chosen among whichever candidate cities dare/deign/want to
participate in the "hosting Wikimania" contest.
All information concerning how to launch a bid for your city/location
can be found on meta:
*http://meta.wikimedia.org/wiki/Wikimania_2007
*http://meta.wikimedia.org/wiki/Wikimania_2007/Bids
*http://meta.wikimedia.org/wiki/Wikimania_2007/Official_requirements_for_bidding_cities
Please follow the instructions on that last page to build your bid.
The Wikimania 2007 organizing team stays at your disposal for any
questions you might have concerning the bidding process and/or the
bidding requirements.
Happy bidding!
Delphine
PS. I have removed all red links to non-existing unoffical bids.
Please only add a link when there is some kind of content to the bid
and make sure the bid is classified with the name of the city, not the
country.
PPS. Dear translators, thank you for translating this message and
sending it to your respective home lists.
--
~notafish
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi there,
I've today developed an extension based on Special:Makesysop that may be a
solution to the problems (at least on en: ) with the process of gaining
adminship. Part of the problem with adminship is that it is somewhat
difficult to remove. This extension may change that. The extension, as
currently configured, allows local bureaucrats to desysop a user. I believe
that this is sensible. If we can trust bureaucrats to set the sysop bit, why
shouldn't we trust them to remove it? Additionally, desysopping is quite a
political issue, and generally requires the intervention of somebody
*familiar with the situation*, not an outsider who has simply been informed.
Therefore, I suggest that we use this extension to allow Bureaucrats to
desysop users in serious cases of abuse of powers. A different process for
desysopping may need to be developed to accompany this - and a policy on
when bureaucrats may use this ability.
Questions, comments and requests for demonstrations are more than welcome.
Andrew Garrett (Werdna)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.4 (MingW32)
iD8DBQFE4aI7ehR2FitQhwARAmX5AKCtfLYt961WAwv0rikgfmbbqqP9SwCgo/0P
UHgmSXxVjXYcgxG5H+AS5qA=
=9mLX
-----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
>But the problem I see with this feature is article forking (as others have
>said). Someone wants to overhaul a page and saves it as a draft, in the mean
>time other users edit the original article and... desaster :)
>Maybe only activate the feature for new articles by default?
Don't we have edit conflicts already? How would these be significantly
different?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.4 (MingW32)
iD8DBQFE4PnGehR2FitQhwARAoT1AJ0SCMB9cndszM3sCiRE/nxmhhKc9QCcCj8n
OvO3r8+eXRRWRaeJ8u1PHS0=
=yZrh
-----END PGP SIGNATURE-----
Hi all. I'm posting here as I consider this fairly high urgency.
There is a factual error on the main page in the featured article for
Caroline Island. I can't edit the page although I have fixed the Caroline
Island article itself.
Caroline Island is not the land closest to the International Date Line
(outside of Antartica) on the western side. [[Big Diomede Island]] holds
this honour at a distance of one mile from the IDL. Caroline Island was
among the first places to see the new year and dawn in 2000 as it is in
GMT+14, which is where the confusion arises.
For more on this see [[talk:International Date Line]] where a discussion
has taken place over the last few months on this issue.
Perhaps someone could fix the main page.
Rob
--
Robert Brockway B.Sc. Phone: +1-905-821-2327
Senior Technical Consultant Urgent Support: +1-416-669-3073
OpenTrend Solutions Ltd Email: support(a)opentrend.net
Web: www.opentrend.net
If you are emailing regarding an open ticket please consider
mentioning the ticket ID as this will assist us in responding
as quickly as possible.
Well I am crossposting this blog text as well as copying it to some
people in blind copy since it involves various projects - as for
Wikipedia: it is about contents creation for small wikipedias (that's
why I changed the original title above).
The original post is at:
http://sabinecretella.blogspot.com/2006/08/omegat-wiktionaryz-betawiki-some…
Your comments and thoughts are very much appreciated.
Best, Sabine
*****
OmegaT, WiktionaryZ, Betawiki ... some questions that need an
answer ...
In the Wiktionary IRC the following questions were made by Connel: "...
considers omegat.org. Is the intent for it to just auto-upload stuff to
WZ? to/from ZW? Or betawiki, or both betawiki and WZ? Or is betawiki
just for WikiMedia total localization?"
That is a lot ... so let me go step by step.
The intent of OmegaT <http://en.wikipedia.org/wiki/OmegaT> is not to
auto-upload stuff to WiktionaryZ <http://wiktionaryz.org> or download it
from there. Nor is it only there for Betawiki
<http://nike.users.idler.fi/betawiki/Etusivu> and WiktionaryZ, even if
it will probably be used for both sooner or later. OmegaT is a CAT
<http://en.wikipedia.org/wiki/Computer-assisted_translation>-Tool that
helps translators to do their work.
What does this mean: imagine you use for all of your translations a tool
that creates a Translation Memory, a file containing the translations
you did segmented into sentences, combining source and target sentence.
Then you do further translations and let the CAT-Tool access these
already translated files. Now if your translation is of a subject you
already translated chances are high that most terminology needed is
already in there and you can even see in which context it was used. So
with OmegaT you do a search on your project and the available
translation memories to see if and how a term was already translated.
This can help a lot.
Now consider a manual - of a machine, a computer, whatever. These
manuals need updates once a new version of that machine or computer is
produced. Normally companies than also just update the description and
parts of it remain the same as before (simply because the functionality
of these parts is still the same). When you then translate you will find
these parts that are unchanged in your translation memory and depending
on how you set your options OmegaT proposes the 100% match or overwrites
the translation part of your project with the already existing
translations. In this way you can save loads of time.
Having the right parser also the MediaWiki <http://mediawiki.org> UI
could be translated in such a way. Now we always will have people that
translate things manually online and who will not use a CAT. This means
that OmegaT should be able to access the single pages containing the
messages on Betawiki, you translate them on your computer and store them
to the page in the correct language version. This is feasible.
Another use will be: creation of contents for small wikipedias. Once we
get our wiki read/wiki write option within OmegaT it is possible to
start a translation of an article, let's say from the English wikipedia
<http://en.wikipedia.org>, and translate it to any language, let's say
the Neapolitan wikipedia <http://nap.wikipedia.org>. This means you tell
OmegaT which page to get on en.wikipedia <http://en.wikipedia.org> and
which page to write on nap.wikipedia <http://nap.wikipedia.org>. The
same is valid for any African language. The advantage of this is: if
there is no online-connection people can work offline on translations.
The translation memories out of these translations should be stored
(WiktionaryZ is already enabled to upload translation memories)
somewhere in order to allow others to access and use them to be faster
and of higher quality during their own translations. Another aspect of
doing things this way is: the proof reading of a translation is easier
since you see the source text above the translation for each sentence.
This easens the job a lot and the quality of the translated article raises.
Now to WiktionaryZ and OmegaT: OmegaT for now has quite a simple
glossary function - you create a tab separated text file and put it into
your glossary directory. While you translate OmegaT shows you the
translation proposals for the words that are present in that sentence
and in the glossary. Now imagine what that means if you connect the
glossary function to WiktionaryZ: the whole repository of data at your
fingertips - of course: considering the mass of data that is online in
WiktionaryZ it becomes very important to attribute domains to
terminology. Often a word can be translated in 20 ways or even more into
another language ... well, it does not make sense if you are doing a
translation about medical equipment that you get proposals from another
domain, let's say machinery - the possibilities from other domains
should only be proposed (showing that other domain) when there is no
entry for medical equipment.
At this stage we don't have this domain structure for terminology on
WiktionaryZ and therefore the data, once we have loads of it online,
cannot be used - it would just create a huge mess and would be very time
consuming. So one of the things we really nees asap is a domain
structure where we can connect the single terms to - the sooner we have
it the better .... otherwise we will have loads of double and triple
work or WiktionaryZ could become completely useless for the use within
OmegaT and as such it would not be of any advantage for translators. Not
even for scientist really ... imagine a biologist search for terminology
and get whatever result ... also those of machinery or whatever other
domain.
Back to the use within OmegaT:
The next step is then: what if the searched term is not in WiktionaryZ
... I already noted that during my last translation - for now it is too
time consuming to add terms to WiktionaryZ and also Wiktionary when you
wish to do that while you are translating - but: it would make so much
sense. So what is planned in the reference implementation for a
translation glossary
<http://meta.wikimedia.org/wiki/Reference_implementation_for_a_translation_g…>
is that when working with OmegaT you get the possibility to add such a
term directly from there. You simply tell OmegaT to add it to
WiktionaryZ with your user ID and you can attribute all the necessary
domains etc. without problems as well as tag the term as "definition
needs to be added". What happens in that way is that WiktionaryZ will
get quite a bunch of very specific terminology over time.
Another use is OmegaT for language lessons - Connel, from en.wiktionary
<http://en.wiktionary.org> thought about it and he is right: OmegaT
could be used for language learning as well ... what if we have a huge
sentence repository and people start to translate texts to study that
language - they do not need a paper dictionary - OmegaT would help them
to see the use of a word in various sentences and they would get the
terminology proposals like the translators. When being back at school or
university (or maybe also online with a language teacher) they can
understand their errors, update WiktionaryZ and the online sentence
repository.
For exams teachers would have a mass of proposals and they could
determine which glossary group shall be included in the exams ... that
is to be thought about ... it was not considered up to now even if there
are already thoughts on how to use WiktionaryZ for language learning.
Did I miss something? Hmmm ... not sure. Well if you have questions:
just ask :-)