【问题标题】:Applying css based on the existence of a page in mediawiki基于 mediawiki 中页面的存在应用 css
【发布时间】:2013-08-01 16:14:29
【问题描述】:

我正在制定一个转录和翻译文档的流程,该流程结合了Extension:Proofread PageExtension:Translate。校对页面根据页面状态(扫描上传、转录、校对等)为列表中的每个链接应用不同的背景颜色,我想将其扩展为也适用于翻译。

使用这样的模板更改背景颜色非常简单:

[[page:{{{1|}}}|<span style="background-color:#48d1cc;">{{{2|}}}</span>]]

问题在于它取决于是否存在英文翻译,该翻译将存储在{{PAGENAME}}/en。这个#ifexist: 函数解决了这个问题:

{{#ifexist: page:{{{1|}}}/en
  | [[page:{{{1|}}}|<span style="background-color:#48d1cc;">{{{2|}}}</span>]]
  | [[page:{{{1|}}}|{{{2|}}}]]
}}

#ifexist 被归类为“昂贵”的解析器功能,每页限制为 100 个,而我有一些索引超过 700 个链接。

显然,我可以只要求在创建翻译时为每个页面手动调用我提到的第一个模板(即在索引中一次一个链接替换 ​​[[page: ]]{{page| }}),但我更喜欢我最初创建每个索引时可以使用的即发即弃的解决方案。


还有吗

  1. 一种超越 mediawiki 中昂贵的解析器功能上限的方法?
  2. 在这种情况下应用条件 css 而不调用 #ifexist 的一些技巧?

或者,我猜,

  1. Extension:Proofread Page 的简单 hack 可以解决这个问题吗?

    MediaWiki:1.19.2
    Semantic MediaWiki:1.8 beta 1
    PHP:5.3.10-1ubuntu3.6 (apache2handler)
    MySQL:5.5.29-0ubuntu0.12.04.2

【问题讨论】:

    标签: css mediawiki mediawiki-templates mediawiki-extensions


    【解决方案1】:

    您可以通过在 LocalSettings.php 中添加 $wgExpensiveParserFunctionLimit 来提高上限。

    【讨论】:

    • 太棒了。有没有理由不把这个上限设置得任意高? (公共编辑被禁用,所有用户都是已知的项目成员。)
    • @MichaelChidester 如果你经常使用它们,页面解析会很慢,所以问题在于公共查看,而不是公共编辑。例如,它们为您提供了 DDoS 攻击的机会
    猜你喜欢
    • 1970-01-01
    • 2014-04-14
    • 2010-11-10
    • 2011-01-27
    • 1970-01-01
    • 2013-02-25
    • 1970-01-01
    • 2023-03-12
    • 2012-10-31
    相关资源
    最近更新 更多