维基百科讨论:合并页面

条目的合并

from Wikipedia:互助客栈/方针

有时候，某人创建的条目只有几句话，而这个条目内容完全可以在另外一个条目中说。例如国际法主体，现在写得很短小，我觉得完全可以在国际法中用几句话就把国际法主体的内容完全涵盖。像这样的条目，还有一些。我觉得这样的条目，完全应该合并，直到有人写了比较长的条目为止--百無一用是書生 (☎) 02:11 2006年5月15日 (UTC)

• (＋)支持。理应如此。不过合并前仍应评估①被合并之条目是否有扩充空间→②是否有人有扩充意愿→③是否已给予了适当的扩充机会与时间等三要件之后再合并。--百楽兔 02:35 2006年5月15日 (UTC)

参见Wikipedia:合并和移动页面。--Wikijoiner 04:52 2006年5月15日 (UTC)

• 国际法主体可以写好大一篇喔。里面涉及历史的演变、不同学说的争议。可以比国际法多很多喔！--Theodoranian|虎儿 =^-^= 05:52 2006年5月15日 (UTC)

其实我主要是以为：对于读者来说，能够在一个页面上阅读某个主题的内容，就不要分散到多个主题上去。除非这些内容非常多--百無一用是書生 (☎) 06:22 2006年5月15日 (UTC)

• (＋)支持。a mergist Gakmo (Talk) 06:39 2006年5月15日 (UTC)
• (！)意见，我认为百楽兔的要求评估的三点意见应予重视，有些情况下，太注重条目的充实而进行合并，对有发展空间的独立条目反而会失去或推迟成长的机会，不少人会为有重要性的小作品进行扩充，但对条目下的章节往往并没有扩充的意识。有些时候，虽然只有几句话的条目，如果它与另一条目的关系相对独立，判研是否是同一主题并合并也应慎重。对于阅读的便利考量，可以通过包含方式得以体现和解决。— fdcn  talk  2006年05月15日07:20 (UTC+8 15:20)
• (！)意见，如果内容非常少，当然可以合并，否则应该保留，但要加上链接。另外提一点建议，如果有不同内容应该合并，但不要轻易加上删除模板，每个人不管贡献大小都是做出了努力，大家可以补充完善，只要不是侵权、恶搞或非常短小，最好不要轻易删除，删除最容易伤害编辑者的参与感。--方洪渐 10:27 2006年5月15日 (UTC)

重复条目之编辑历史是否须合并？

两个先后建立的条目在分别经过多次编修后，最后被合并为一个条目（留下一个，另一个改为重定向页），此时是否还需要将两个条目的编辑历史跟着合并？如果不合并，最后成为重定向页的条目编辑历史大概就再也不会有人注意到了；如果合并，会因为两条目编辑时间的交错，或让合并后的编辑历史变的很混乱，甚至难以回顾与分析。不知道大家觉得此状况的页面编辑历史是否需要合并？—Alberth2-汪汪 2009年1月31日 (六) 08:39 (UTC)

我觉得在编辑摘要某处加入一个指向原条目历史的链接即可--Liangent（留言） 2009年1月31日 (六) 14:14 (UTC)

合并编辑历史会比较好--Ws227 (留言) 2009年2月1日 (日) 01:26 (UTC)

合并编辑历史会比较好，并在编辑摘要某处注明—Jazecorps Nekivary 2009年2月1日 (日) 04:19 (UTC)

(！)意见：编辑摘要可以在执行合并移动时注明移动是为了合并编辑历史；但是在合并完成的编辑历史中，仍是无法分辨哪些编辑是从不同页面合并过来的，这也是个人认为会产生混摇困扰的部分。—Alberth2-汪汪 2009年2月1日 (日) 09:39 (UTC)

(！)意见：一个建议，如果两页面的编辑历史时间没有重叠，可以以某一天做明确的分线，例如：页面A的编辑都在2007年12月以前，页面B的编辑都在2008年1月以后，就可以将其编辑历史合并。但如果两页面编辑历史的时间是相乎交错的，究竟量避免合并，以避免合并后的页面编辑历史难以阅读。—Alberth2-汪汪 2009年2月8日 (日) 01:36 (UTC)

• (－)反对。合并不是移动，不必也不应合并页面编辑历史，请参见en:Wikipedia:Merging。--Pengyanan（留言） 2012年8月14日 (二) 05:58 (UTC)

移动

有没有哪位能界定一下“Wikipedia:重复条目”、“Category:需要合并的条目”和“Wikipedia:移动请求”三个页面的分工有什么不同？

事缘当我动手合并河南郡、三川郡、迦帕多家教父、加帕多家教父时，却被退回了。

查上述两对条目实为积压已久的“Category:需要合并的条目”，前者（三川郡及河南尹）的合并，更是已在“Wikipedia:重复条目”页面经过长足的讨论而达到共识后才进行的。三川郡及河南尹的合并于2009年1月25日08:54被某用户退回，而该用户的再前一项改动则发生于2009年1月25日08:53，足见该用户在进行退回前，对该两条目的合并的前因后果，不可能有超过一分钟的阅读时间去理解。再查该退回合并的用户的其他“用户贡献”，发现该用户实素有盲目退回的习惯。

然而，当我检举该用户的盲回退回时，又被劝喻说“条目不能手动移动，要由管理员处理。”

我见“Category:需要合并的条目”页面只是挂上“本页面是一个积压的工作，需要老练的用户关注”，并没有说非由管理员处理不可。

结果，要做的没人做，大量积压，去做的被人退回，退回者自己又不做。

如果我每次对前两个页面的条目进行合并，都必须被退回且必须送交“Wikipedia:移动请求”页面处理的话，那么干脆只保留“Wikipedia:移动请求”好了，前两个页面要来干嘛？--210.6.97.145 2009年2月7日 (六) 06:11 (UTC)

确实常常有人混淆，不过移动请求和重复条目是完全不同的。移动请求是只有一个条目及内容，当无法移动到新名称时，才需要到移动请求提出；此外，现在也会处理被以剪下贴上移动的条目的编辑历史。由于某些情况下的移动只有管理员可以处理，因此移动请求必须由管理员处理，如果被积压确实是管理员该设法处理。而重复条目则是同时存有两个先后建立的条目，但可能后来被发现其实是可以合并为单一条目，因此要将两个的内容合并，并将其中一个改为重定向页；这种工作其实就不需要管理员的权限就可以进行，任何熟悉维基百科的人都可以处理，只是问题常常在于要如何决定将哪个条目改为重定向页？取得合并的共识也是处理重复条目最难的部分，也因次重复条目会更容易被积压。—Alberth2-汪汪 2009年2月7日 (六) 06:59 (UTC)

谢谢回复，那么，套用到河南郡、三川郡、迦帕多家教父、加帕多家教父这几个案例时，应该如何处理才对？我确实是在“Category:需要合并的条目”找到的，也确实被退回了，而该退回动作也被肯定了，是不是又该交由“Wikipedia:移动请求”处理？--210.6.97.145 2009年2月7日 (六) 07:42 (UTC)

有时候可能只是误会，或许其他人没注意到该页面已经有合并的讨论及共识，这时候建议可以直接去回退者的对话页提出说明、沟通，应该有助于解决争议。另外，也建议在合并同时善用编辑摘要，让他人知道为何自己要做此修改。因为这些动作并不是在进行条目的移动，因此也不需要到移动请求提出。—Alberth2-汪汪 2009年2月7日 (六) 07:52 (UTC)

想问一下，直接手动重定向岂不是让被Ａ条目的原编辑历史停止了？原编辑者的功夫岂不是白费？这种情况不是不应该手动重定向而是由管理员移动再合并编辑历史吗？--91.142.12.62 (留言) 2009年2月7日 (六) 07:58 (UTC)

可以参考Wikipedia:合并和移动页面#如何合并页面，在合并两页面时，编辑历史的合并并非是必须的；目前的作法是认为有此需求的话，可以在合并完成后再至移动请求提出，但提出前此两条目必须先将内容整合完成，才能方便管理员进行编辑历史的合并。不过个人并不建议所有合并的条目都将编辑历史合并，因为会产生让编辑历史混乱的问题，可以参考我在Wikipedia:互助客栈/方针/存档/2009年2月#重复条目之编辑历史是否须合并？提出的讨论，如果有任何建议方式也欢迎一起提出。—Alberth2-汪汪 2009年2月7日 (六) 08:19 (UTC)

Wikipedia:重复条目/存档/2008年中为什么还有未解决便存档的请求？

遇到内容雷同的两个条目究竟是不是应当到Wikipedia:重复条目提出？我发现我在那里提出的请求，结果无非是（一）没有管理员搭理便被存档；（二）被IP用户或管理员手动合并页面，而且这种手动合并的行为似乎也被其他管理员们所默许。于是，遇到铝热剂和铝热法两个应当合并的条目后，我将铝热剂手动合并到铝热法，并在将 Talk:铝热剂 转移至 Talk:铝热法 后，将其提交快速删除。然而该提删页却被管理员挂上了hangon模板，并被提到了Wikipedia:移动请求，要求“合并编辑历史”，致使两者编辑历史混在一起，甚至出现了我将“铝热法”重定向到“铝热法”的记录，我的编辑被回退，并被恢复，最后的页面历史成了这样。难道管理员认为这样互相交错、混乱不堪的编辑历史才是正确的？铝热剂 只有一个主要贡献用户，其内容也大多与 铝热法 相同，手动合并时编辑摘要中已有记录，如果想要看合并前的页面历史，完全可以去相应的页面历史页中看，两者互不影响，然而合并后页面历史中只有页面移动的记录，并没有合并的记录，管理员们却非要使编辑历史变得凌乱，让看页面编辑历史的人一头雾水。如此双重标准，实在令人费解。—Choij (留言) 2009年2月7日 (六) 09:37 (UTC)

你提出的疑问可以分两点来说明：

• 其实Wikipedia:重复条目并不是要由管理员来处理的工作，因为这项工作并不需要管理员的权限，是任何人都可以处理的；而重复条目的合并，确实也就是“手动”将两条目的内容集中在一个上，再将另一个改为重定向。至于未被处理就被存档，你举的例子那就是我的疏忽了......。
• 完成合并后，是否需要将原本的两条目编辑历史跟着合并，这目前尚未有一致的共识，个人也是与你一样认为一般状况下不要合并比较好，因为会让编辑历史交错，难以阅读（可以参考上方“重复条目之编辑历史是否须合并？”一节之讨论）；但是还是有许多人认为为了保留两条目所有贡献者的纪录，应该合并。所以才会有人提出将两编辑历史合并的请求，并获得其他管理员的认同并执行。这个议题确实需要更多人一起讨论，寻找一个两全的解决方案。

—Alberth2-汪汪 2009年2月7日 (六) 13:43 (UTC)

当条目A请求合并到条目B时，探讨“合并讨论应该留在哪个条目”这议题。

最近遇上一个问题，我看Wikipedia:合并和移动页面并没说明合并讨论应该放在哪个条目。现在我提出问题是：当条目A请求合并到条目B，请问讨论该留在Talk:A还是Talk:B？因为模板设计是Template:Mergeto这样，当你使用它去提出合并时，万一你有讨论需求，击选（讨论）进去，系统会帮你指向Talk:B；然而，我想法是条目B并没提出合并，而是条目A被请求合并，万一合并不成，那么讨论放在Talk:B，若是读者哪天在看条目A也有相同疑问：“条目A明明就是条目B”，但他不知道有人提出过合并了，另一种情况是有人无意间看到“条目A”的修订历史有记录使用Template:Mergeto的页面这笔编辑，可是在Talk:A没看到讨论，这二种情况都会使人无法看到合并讨论，即使熟悉维基操作的人，也还是得特地去找条目B才会看见Talk:B有没有提出合并讨论，若是对不熟悉的人来说，或许真的会有人不知道条目A过去有人提出合并的纪录了。--111.252.233.57（留言） 2016年6月8日 (三) 10:48 (UTC)

我的习惯是在Talk:B开讨论，然后在Talk:A写上“关于此条目的合并讨论请至Talk:B”，如此一来就不用担心有人没注意到讨论纪录了。--M940504（留言） 2016年6月9日 (四) 13:12 (UTC)