这里是 LitePress 社区旧贴存档，您可以在此留言或提交新的回应和信息。
《参与者列表》有2,005条评论
-
-
在站点 Nginx 的
location /中加入以下配置：deny ::;
参见：
Nginx 官方文档中对
ngx_http_access_module的描述：http://nginx.org/en/docs/http/ngx_http_access_module.htmlIBM 官方文档中对特殊 IPv6 地址的描述：https://www.ibm.com/docs/en/zos/2.4.0?topic=applications-special-ipv6-addresses
来自中国, 河北, 秦皇岛回复 -
-
-
以下语句按执行优先级拆解一下：
isset($options['smtp_password']) ?? '111';
最优先执行的
isset($options['smtp_password'])的返回值是 true 或 false。之后使用
??来判断isset($options['smtp_password'])是否已定义，想当然的是按 true 处理的，于是这个语句最后返回的值就是三目左侧的 true 或 false，而不是选项值。正确写法应该是：
$phpmailer->Password = $options['smtp_password'] ?? '111';
来自中国, 河北, 秦皇岛回复 -
-
-
-
-
刚整理术语表的时候突然想起来，中文翻译的时候是不是可以忽略掉单复数了。这样术语表里只记录单数，然后程序匹配的时候单数和复数都去匹配这条术语？不知道这样会不会产生一些翻译错误。
来自中国, 河北, 秦皇岛回复 -
现在这个阶段讲的话我觉得就是你说的这样。
更深层次阐述一下，这个和我本人一直奉行的发展策略有关。
我觉得我唯一成功的方式是通过一个优势点去撬动其他点，在不断的资源整合中变得强大。这个策略适用于我在做的几乎所有的事情。
往大的方面举例子，就好像我从12岁就开始自学编程，对计算机的了解和编程知识就是我作为一个社会底层人士在前期积累中的一个优势点。在日后的日子里我不断通过这个优势点去撬动其他资源，比如说老师们更愿意和我保持朋友关系，而不仅仅是上完课就走的塑料师生关系，原因就在于我有一技之长，虽然作为一个学生在地位上无法和他们相提并论，但是我可以和他们形成优势互补，他们自己做项目或者帮别人做项目或多或少都要咨询我。
往小的方面说，比如WP-China-Yes这个项目刚起步的时候，很多人说“我们早就想到了，只是碍于成本没做”。但是我一直在说的是只要有用户使用，我就可以靠用户资源这个优势点去拉动赞助来填平成本，我觉得日后的事实证明我是对的。
整个逻辑就好像是手摇式拖拉机的启动过程，单凭发动机自己虽然力量存在，但是找不到做功的着力点（类比一下，就好像现实世界中我的老师这一力量存在，赞助我的商家这一力量也是现实存在的，他们只是对我或我在做的事来讲找不到或者说不想找到做工的着力点），而我要做的就是去用摇把摇一下（创造优势点），给发动机一个初始的力，有了这个初始的力后发动机的各个机件就会不断的加入到工作循环，直到所有机件都被带动起来之后，甚至我不摇它它也会凭借发动机做工而运转下去。
前面还只是拿我个人发展举例子，如果代入WordPress生态发展上来讲：
我觉得WordPress生态是根上烂了，也就是我在发展计划里说的是，强制GPL及不支持国内的小程序体系。前者阻碍生态原始积累，后者把WP锁死在PC端。
所以说做这件事第一步就是刮骨疗毒重新打一套新的地基（新的LitePress发行版与liitepress.cn），之后也就是融入我前面讲的通过优势点不断整合资源的思想。
比如通过China Yes的存量用户与开发者交换流量的方式要求开发者入驻，越多的开发者入驻后筹码和能力就会越大。
再比如通过完善的翻译和其他优势以及适当的引导，撬动用户主动参与翻译过程。这就是咱们本次讨论的话题，我觉得通过机器翻译填充起来的100%汉化的仓库或许是打出与w.org差异以撬动用户在新体系下贡献翻译的点，我需要做的就是集中力量加大这一优势点，以让更多人参与进来，由大家一起完善资源，而不是尽善尽美地都自己去做，这样老实说也不大现实，就好像我作为一个穷人不可能仅凭自己完成所有积累然后实现最终理想。
通过以优势点不断撬动资源的方式，在不久的将来，很大一部分的开发者、译者、普通用户将会参与到这个新体系中，待到时局一变（w.org被墙或再来一次429），届时就是彻底实现整个计划的时刻了。
之后目标就会从内部统一转换为向外扩张，理想状态下WordPress将渗透入中小企业应用场景的方方面面，而不止于建站系统。
改变世界或许太远了，先从改变行业开始吧！
来自中国, 河北, 秦皇岛回复 -
-
在证书配置那勾选强制https，这样访问http就跳到https了，http不能单独访问
回复 -
我想了想：litepress.cn 的术语表是用于对机器翻译的错误词汇进行纠正的，所以应只需包含机器翻译会出错的术语，这样条目也不会太多，也顺便减少了你说的替换过多而无法翻译的情况，这样可能就需要对术语表进行适当的增减了。
来自中国, 广西, 柳州回复 -
-
-
-
按道理讲术语表属于是技多不压身的东西，对于人类翻译的话条目理应是越多越好。
我前面表达的观点主要是从机器翻译填充和成本投入的角度出发的，因为举个例子，如果一个句子比如说10个单词，其中有3个都命中术语表被替换成代码的话谷歌就翻译不出来了。
同时，对于我们来讲，整理数据这种枯燥的工作只能是我自己做，毕竟己所不欲勿施于人。但是我的时间老实说也蛮紧张的，所以说没法在这上面投入太大精力。目前计划术语表整理的规模大概在200条，今天下午实践看，精校20条+收集整理资料的时间大概是一个小时，200条大概是两天全天的工作量，但是老实说这种枯燥的工作我很难满效率搞两天，所以总时间大概延长一倍。。
总结一下就是综合以下三个方面的考量，我现阶段希望建立一个较小的术语表：
- 利于机器翻译
- 较小的成本投入
- 大而全的术语表似乎并非必要
其实对机器翻译的影响应该可以通过技术方案规避（比如说限制下机器只读取某些术语），最主要的问题还是成本投入。
如果你愿意整理的话我不介意白嫖一份（大笑。
当然我整理的你也可以导出使用。
来自中国, 河北, 秦皇岛回复 -
-
我是准备打算用 wp-info 把 wp.org 的术语表重新整理一遍的，然后按照情况去除掉一些条目，然后把以前术语表的一部分条目保留下来（仅限整理后的数与表不包含的条目，即整理之前手动添加上的条目）
来自中国, 广西, 柳州回复 -
-
我在WordPress.org的支持文档中翻到了这一篇官方建议的术语表列表：
https://wordpress.org/support/article/glossary/
按上面说的，术语表存在的意义在于让不了解WordPress的人能正确的使用 WordPress专有的术语 进行翻译，而不是对通用词汇提供翻译指北以实现类似《英汉词典》这种大而全的词汇对照。
而上面的文档中列出的也就是如前所述的“WordPress专有术语”。
wp-info.org上的术语表中存在很多类似“administrator”这种几乎只对应唯一翻译的词汇，以及类似“approval”这种在不同地方存在不同译文的词汇，这样的话我感觉整体范围太宽泛了，变成了前面说的《英汉词典》而有悖术语表的初衷。
如果是想通过术语表让翻译保持一致的话，我在想是不是也要提供一个翻译一致性检查工具，由这个工具来确保翻译一致，而不是通过术语表。
来自中国, 河北, 秦皇岛回复 -
-
-
没有太好的办法，我上次也被刷的裤衩都要卖了。
又拍云提供了访问速率限制以及防CC功能，但是实际测试来看并不会起任何作用。
该问题目前唯一的解决方案就是如果你网站不需要面向老外的话可以在屏蔽掉海外IP，又拍云提供访问地域限制功能，海外IP屏蔽后能预防绝大部分CC攻击。
其次就是在被打的时候手工通过日志分析攻击者IP，然后手工拉黑了，不过这个在面对攻击者使用代理IP的情况时就很无力了。
高风险的业务不建议使用这种按量付费的CDN，就算换阿里、腾讯也一样给你刷到破产。最好是使用百度云减速这种预付费的CDN，不管你被刷多少反正一年就几百块，超量了最多回源而已。
只是普通的个人博客的话可以不用担心这个。我自己的博客日IP大概200，四年了也没被打过一次。前面说被刷的是Cravatar的头像服务。
来自中国, 河北, 秦皇岛回复 -
这两插件我都用过，第二个有第一个的功能，做过简单测试，第二个的效果不是很好，有的地区打开网页秒开，有的地区打开慢了几秒，我现在用的fastese cache+redis object cache
来自中国, 四川, 成都回复 -
这个检索了下官方的文档：https://developer.wordpress.org/block-editor/reference-guides/block-api/block-variations/
目前的代码编写已经符合文档要求了，不能出现在常用区块中可能是古腾堡对区块变体的处理还有BUG，因为我和老李头都不是JS开发方面的专家，所以这个问题得搁置了。
来自中国, 河北, 秦皇岛回复 -
类似WP大学这样都聚合到一页上提交：https://www.wpdaxue.com/sitemap.xml。
他使用的是这个插件：https://litepress.cn/plugins/www-xml-sitemap-generator-org
来自中国, 河北, 秦皇岛回复 -
-
发表评论