Partkeepr: Partkeepr 维基

目前，我唯一设法使“工作”的方法是使用谷歌缓存页面。 您只需搜索相关的 wiki 页面，google 就会显示结果，然后单击链接旁边的小向下箭头而不是单击链接本身，然后单击缓存。 它将没有样式，但内容在那里。 ：或使用archive.org去http://web.archive.org/web/20180310044536/http ：//wiki.partkeepr。 org:80/wiki/Main_Page

我确实希望 wiki 在某个时候回来，即使只是在 github 上的文件夹中（或在此处的 wiki 选项卡中）作为裸 html。

wiki 好像重新上线了。

好消息！ 关闭。

无论如何，有谁知道 wiki 的托管位置？ 这仍然是@Drachenkaetzchen 的责任吗？ 在另一个问题中描述了Partkeepr目前有点卡住的问题。 这可能是帮助@Drachenkaetzchen并在其他肩膀上承担责任的好方法。 然后，需要 Wiki/SQL 的备份。

@Gasman2014总而言之，在这个问题得到长期解决之前，我会投票重新开放。

我和@christianlupus 在一起，我会说将它托管在 githubs 的 wiki 部分，这应该会减轻 @Drachenkaetzchen的服务器和肩膀的负担。

鉴于长期解决方案的可取性以及@C44Supra和@christianlupus的建议，即尝试通过归档此数据并通过 github 独立托管来支持 Felicia @Drachenkaetzchen ，我将重新打开它。 wiki 中的信息对安装故障排除非常有帮助 - 特别是在主要设置指南中未描述的利基情况下。 此信息应与代码库一起提供，以获得最大的可用性。 我很高兴看到 wiki 已经恢复，但也许它可以在没有太多工作的情况下与 github wiki 部分结合，其中还包含一些有用但额外的和不同的信息。

如果有人可以提供一种方法来自动将托管的 wiki 移动到 GitHub，请继续告诉我，但前提是您实际测试了这种机制。 对于这种机制，一个简单的谷歌会产生很多结果，我没有时间或精力去研究它们。

如果您需要对当前 wiki 或数据库转储进行某种 API 访问，请告诉我。

我愿意尝试准备这个。 我将尝试迁移到我的个人帐户中的 wiki。 就我所见，我只能迁移最新版本的维基，需要一些手动调整。

我尝试将 wiki 文件迁移到 github。 结果在这个 repo 中可见。 仍然需要一些小的修改（如删除拼写错误、重命名页面、组织文件等）。

不幸的是，自动导出到 XML（从 mediawiki 导出的标准方式）有一些缺点。 这样，页面的历史记录就会丢失，并且不会导出任何媒体文件。 我手动下载了它们，但元数据（如标题和替代文本）没有移植。 此外，github 的 wiki 比 Mediawiki 更受限制，导致例如据我所知不可能出现子页面列表。

@Drachenkaetzchen我会请你验证维基是否可以这样使用。 然后，如果这对您来说没问题，您可以简单地在 Partkeepr 页面上安装我的 repo 中的页面。 如有疑问，请联系我，我将非常高兴和自豪地提供帮助。
PS：我将您添加为 repo 的合作者，以便您可以使用它。

欢迎所有其他人通过 wiki 寻找我遗漏的错误。

@Drachenkaetzchen我会请你验证维基是否可以这样使用。

我很困惑，我到底应该验证什么？

我将 wiki 移植到了 github。 请检查您的质量标准是否可以接受这项工作，我没有完全搞砸。

我想你应该问问用户 ;) 我很少使用维基。

我建议在邮件列表上征求反馈

我在邮件列表上留言了。 此处交叉引用仅用于完成。

我建议我们使用 github Pages 而不是 github wiki。 我们将有更多关于文件组织的选择，两种解决方案之间没有太大区别。 有没有更适合 github wiki 的选项？

@Drachenkaetzchen我没有得到其他用户对 wiki 迁移的太多关注和回应。 你有任何时间表或我们将如何在这里进行？ 我会根据使链接工作和文件名有用来准备迁移。 由于这是手动工作，我不想在以后不使用时不这样做。

我真的不能给任何反馈。 我只能为该项目做一些简单的管理工作。

好的，然后我请@dromer发表意见。

大家好，我还没有看到任何关于将 wiki 迁移到 github 的讨论。

我确实认为将我们拥有的所有信息集中到一个资源中是有意义的。 但我们迁移的信息也应该是相关的，并且应该去除遗留的东西。

我在 github wiki 和页面方面的经验几乎不存在，所以我无法在那里发表评论。

[编辑：啊页面就像一个 jekyll 网站或其他东西。 那么对自动格式化程序有什么偏好吗？]

啊页面就像一个 jekyll 网站或其他东西。

对，差不多就是这样。 顺便说一句，维基也是如此。 不同之处在于页面旨在用于站点，而维基用于粗略的一组或多或少的短信息块，这些信息未经排序/组织。 这让我（在我的第一次迁移测试期间）引起了一些麻烦，因为底层服务器会自动猜测文件名，例如区分大小写导致问题。

你这句话是什么意思

对自动格式化程序有什么偏好吗？

你的意思是样式/布局？

对不起，我的意思是网站生成器。 我相信 github 页面可以使用 jekyll 以外的其他页面吗？

我不确定 jekyll 将是组织 wiki 的最简单/最好的方法，但与 github wiki 相比究竟有什么优势？

我认为我们暂时还没有必要托管主要的 partkeepr 网站，让我们关注诸如 wiki 之类的最新信息资源。

我认为 github wiki 上也有一些零散的页面。 所有这些都应该与项目当前状态的相关且正确的信息相融合。

对不起，我的意思是网站生成器。 我相信 github 页面可以使用 jekyll 以外的其他页面吗？

没问题。 可能是，我还没有完全解决。

我不确定 jekyll 将是组织 wiki 的最简单/最好的方法，但与 github wiki 相比究竟有什么优势？

好吧，老实说，就我而言，差异很小。 两者都采用降价（或任何 pandoc 可以读取的格式）并以一种很好的方式对其进行格式化。
我发现了一个问题，维基不允许命名空间，链接和相应文件名之间的映射是一种启发式：

• wiki 包含两个页面，它们仅在标题（ 1 , 2 ）的情况下有所不同。 我必须手动删除其中之一以使启发式选择正确的。
• 子文件夹（用作一种命名空间）只能在使用 git 手动签出时创建。 链接不遵守此命名空间，因此您只能拥有每个文件名一次，从而使文件夹结构不实用。 我不知道github如何选择要命名的页面，以防两个文件具有相同的名称。

github Pages 解决方案的另一个优点是您可以在本地运行 jekyll 来检查外观和所有链接，而无需发布。 另外我认为你可以做更多的造型（但我必须检查一下）。

我认为我们暂时还没有必要托管主要的 partkeepr 网站，让我们关注诸如 wiki 之类的最新信息资源。

不，我认为这是目前位于一个很好的位置。
虽然我可能想指出有（？）使用 github作为主主页的

这个问题的重点是在服务器出现故障的情况下保留当前的 ​​wiki。

我认为 github wiki 上也有一些零散的页面。 所有这些都应该与项目当前状态的相关且正确的信息相融合。

是和否。 它应该与软件的最新版本有关。 但是我认为该项目中的文档相对较少。 我知道我们缺乏人力，但没有文档，用户在查看软件功能如何工作时会遇到更多问题。
因此，我保证将文档更新到最新版本，但保留例如来自旧州的迁移指南，但这些都是针对相当长一段时间内严重过时的版本（可能拆分一些页面以使其更具可读性）。

我希望我们在社区中获得一些牵引力（你可能会嘲笑我的乐观想法），通过添加提示和技巧来帮助设置事物。 在过去几天我处理古老问题的过程中，我从社区成员那里看到了一些不错的想法，这些想法可能值得在类似 wiki 的页面中提及。

无论哪种方式我都很高兴..但是有一个维护者会是一个好主意......我的经验是这些东西老化得很快

那是真实的。 您的意思是有一个人专门负责使文档保持最新状态？

我也可以以这种方式帮助该项目。 不要误会我的意思：我不是在逼着这个位置。 应该协商一致决定。
目前没有太多新的东西需要记录。 主要是更新现有的。 如果项目再次受到关注并且新代码被编写/更改，这可能会改变。 然后文档的维护者依赖于开发人员的支持，因为经理无法理解所有技术细节。

我今天有更多的精力，所以这里有一些想法：

• 当前的 wiki 使人们很难贡献文档，因为我不得不禁用注册，要求我手动创建用户
• GitHub 集成 wiki 使导航变得困难，特别是如果有许多页面没有从主页正确链接。
• 贡献文档必须很容易。 最好是用户可以简单地单击“编辑页面”按钮来编辑现有内容，并单击一个按钮来创建新内容。 我喜欢的一个例子可以在这里找到： http :
• 但是，在前面的示例中没有“新页面”按钮，不知道如何做到这一点

• 当前的 wiki 使人们很难贡献文档，因为我不得不禁用注册，要求我手动创建用户

这在某种程度上与维基矛盾，但我理解需求。

• GitHub 集成 wiki 使导航变得困难，特别是如果有许多页面没有从主页正确链接。

这是完全正确的。 我觉得维基的构建方式并不美观。 为了简化导航，必须确保在整个 wiki 中存在良好的链接网络。

• 贡献文档必须很容易。 最好是用户可以简单地单击“编辑页面”按钮来编辑现有内容，并单击一个按钮来创建新内容。 我喜欢的一个例子可以在这里找到： http :
• 但是，在前面的示例中没有“新页面”按钮，不知道如何做到这一点

他们使用 github pages 功能，但比基本设置更复杂。 我还没有完成所有事情，但我可以调查事情......

在https://readthedocs.web.cern.ch/display/PARTK共享的本地 WIKI 中主动收集用户信息
他已提出将此信息移植到其他位置，但需要项目团队提供指导。 可以在 PartKeepr Google Groups https://groups.google.com/g/partkeepr-users/c/ehqapXqyY0o/m/1VWkA00dDAAJ 中找到此线程