Hello, you have come here looking for the meaning of the word Help talk:Transwiki. In DICTIOUS you will not only get to know all the dictionary meanings for the word Help talk:Transwiki, but we will also tell you about its etymology, its characteristics and you will know how to say Help talk:Transwiki in singular and plural. Everything you need to know about the word Help talk:Transwiki you have here. The definition of the word Help talk:Transwiki will help you to be more precise and correct when speaking or writing your texts. Knowing the definition ofHelp talk:Transwiki, as well as those of other words, enriches your vocabulary and provides you with more and better linguistic resources.
Latest comment: 17 years ago5 comments2 people in discussion
HI I think the following needs clarification:
"Tag it with {{merge|{{PAGENAME}}}} or if the existing page starts with a lower case letter tag it with: {{merge|{{lcfirst:{{PAGENAME}}}}}}.
Having gotten this far on a list of items I have marked to merge, I don't know what next to do. If only admins can merge with a merge bot, we should say something like "An admin bot will merge them" or if its like wikipedia, users are encouraged to merge documents manually, but to leave a flag on the redirect page that says {{r from merge}} underneath the redirect command, which tells other users to retain redirect page as a history of a merge. Should Wiktionary copy that? If so the template Template:r from merge needs to be created. Goldenrowley 23:01, 26 October 2007 (UTC)
Please note this is only to save both history pages (if necessary). Goldenrowley23:14, 26 October 2007 (UTC)Reply
Well, you are breaking new ground for us, in general. (No one has taken the effort seriously, so far.) I don't see any problems with merging the content and marking the history as being in need of a sysop-history-merge. AFAIK, there is no bot process that anyone has written to do the history merges. The sysop steps are as follows (correct me if I'm wrong!):
delete target
move tw page to target
restore all versions
manually edit the "last good" version, removing "{{merge}}"
Well If administrators can and are willing to do sysop-history-merges, I can offer to make that the final point on these instructions (noting where history-merge instructions are, for new administratoris... where are they?) Otherwise I would suggest we just copy Wikipedia's already hashed out procudure and just mark merged pages as keepers, to redirect indefinitely purely for the legal reasons to document our sources. Saying that I work in a legal dept but am not a lawyer.Goldenrowley20:02, 27 October 2007 (UTC)Reply
I guess I should point out that the reason a Wikipedia article might be merged is very much opposite Wiktionary's needs. As a rule, we want entries split into separate entries. For Transwikis (and Transwikis only) the merges need to happen. To comply with the GFDL, we do a history merge. So, copying Wikipedia's approach might not only be wrong (non-GFDL compliant for how we use it,) but might also mislead people into thinking that is acceptable.
There is a brief "new sysops" guide floating around somewhere, but it doesn't go into any detail about merges (if it mentions them at all.) So, any verbiage you come up with is likely to be quite helpful. --Connel MacKenzie20:28, 27 October 2007 (UTC)Reply
Two merge types
Latest comment: 16 years ago8 comments2 people in discussion
I guess I'm seeing the problem more clearly now. There are two types of merges:
Page content merges (that anyone can do)
History merges (than only sysops can do)
For content merges, yes, the Wikipedia process (linking the "from" page in the edit summary) is fine and GFDL compliant...partially. Since this is only used for Transwikis, the history itself should be merged over. This means that the content should just be added on the target page, removed from the transwiki page, and replaced with the history-merge request tag, {{merge}}.
I think it would help immensely, to not commingle the two issues. Perhaps we could have a {{content merge request}} template for tagging potential content merges. That would allow us to reserve {{merge}} to the understood role of history merges only.
Does what I said, make any sense at all? Should I rephrase it? Comments?
How about "merge" stays non-assuming and as the parent category with at least 2 sub-categories? I can see sub-category within the merge category where one can separate "content merge" requests versus complete "over-write" requests? Goldenrowley20:36, 29 October 2007 (UTC)Reply
Yes I think so, it will also allow someone (me) to help finish the instructions for each. In the meantime editors who dont have time or expertise to make judgement calls can put them in "merge" for someone else to think about. Goldenrowley22:04, 29 October 2007 (UTC)Reply
What the license mandates
I copied this from the GNU Free Documentation License. Bolding mine. It dictates to keep all renditions of a content-merged page, although collect all the history in one place. Question do administrators have the ability to do collect all the history in one place?? . This wold only apply to the pages Transwiki'd articles where elements were merged into a page already at Wiktionary. Goldenrowley03:36, 4 November 2007 (UTC)Reply
"5. COMBINING DOCUMENTS
You may combine the Document with other documents released under this License, under the terms defined in section 4 above for modified versions, provided that you include in the combination all of the Invariant Sections of all of the original documents, unmodified, and list them all as Invariant Sections of your combined work in its license notice, and that you preserve all their Warranty Disclaimers.
The combined work need only contain one copy of this License, and multiple identical Invariant Sections may be replaced with a single copy. If there are multiple Invariant Sections with the same name but different contents, make the title of each such section unique by adding at the end of it, in parentheses, the name of the original author or publisher of that section if known, or else a unique number. Make the same adjustment to the section titles in the list of Invariant Sections in the license notice of the combined work.
In the combination, you must combine any sections Entitled "History" in the various original documents, forming one section Entitled "History"; likewise combine any sections Entitled "Acknowledgements", and any sections Entitled "Dedications". You must delete all sections Entitled "Endorsements."
I've expanded the instructions substantially to clarify content merges, adding nothing new just the unwritten procedures. If we've come to a consensus, I can work next on tweaking this to differentiate the name of the "content merge" template from the "replacement page merge" template. Goldenrowley04:27, 4 November 2007 (UTC)Reply
So, since Wiktionary has no Wiktionary-specific invariant sections, just the GFDL, the only acceptable way to history merge is to have a sysop delete/move/restore/edit merge them. Thanks for digging up the relevant portion of the license. --Connel MacKenzie22:19, 5 November 2007 (UTC)Reply
Potential Import problem
Latest comment: 16 years ago3 comments2 people in discussion
I haven't seen this in a very long time, but it is something that anyone interested in transwikis should keep an eye out for. When re-transwiki-ing a previously transwiki'ed and redirected entry, newer edits from Wikipedia can supersede the redirect. Since the current bot tries to refuse to automatically re-transwiki entries, this is not such a big problem right now. --Connel MacKenzie22:43, 5 November 2007 (UTC)Reply
This nasty glitch has made merging more difacult than planned. The history of the over written pages aren't even showing unless you do a final "manual" restore save of the final page. After trial and error this month, I've gone ahead and clarified and simplified steps and offered work-around for the glitches. Goldenrowley05:14, 14 November 2007 (UTC)Reply
Note: I found the "redirect" step was causing some glitches before a merge (it appears to make it hard to identify what to merge, and also puts the history in a circular loop after the merge) thus removed "redirect" as a step. Goldenrowley05:14, 14 November 2007 (UTC)Reply
Latest comment: 15 years ago7 comments5 people in discussion
I propose to delete Transwiki entries over a year old where its clear Wikipedia kept the article and keeps editing them, even though they Transwikied them to us. We have a backlog from prior years here of 'Pedia imports, particularly from Feb 2007 when our Bot transferred about 1200 entries in one month. There are 3 reasons: (1) we have a backlog going back 3 years of imports; (2) Wikipedians can add considerable edits in one year on any entry, so our imports go out of the date comparatively (3) and any entries Wikipedia keeps means the history of edits is cloned. I propose to work from the Wiktionary export list from 2007 as a start: , to identify the entries Wikipedia kept. Some good examples are:
Support. AFAIK, you're the only person with the intestinal fortitude to deal with these in bulk, so AFAI am concerned, what you say goes. :-) -- Visviva05:48, 29 January 2009 (UTC)Reply
I support this proposition. Shouldn't it be bot-doable? (Any such bot would have to be able to check histories, though.)—msh210℠21:42, 29 January 2009 (UTC)Reply
Seeing how much sense it makes, I just started with the old imports from 2005-2006. I eliminated 20% from year 2005 that were kept and better handled on Wikipedia. I look forward to the day we can finish Transwiki in process 2005 and 2006 lists. However we're down to the "hard words" and other languages. I am recruiting help there. Goldenrowley04:11, 14 February 2009 (UTC)Reply
Keep transwikied glossaries. Coming late here, I propose to keep transwikied glossaries in Wiktionary, regardless whether they are kept in Wikipedia, no matter how old they are. Processing glossaries takes a lot of time, and they are useful to have in Wiktionary appendix namespace. --Dan Polansky16:59, 23 July 2009 (UTC)Reply