All posts by FishTank

The handler for OGG files likely has not yet been ported to UCP.

<div class="quote"><i>MisterWoodhouse wrote:
  <p>This week is a bit different, so pitter patter, let's get at 'er. </p> </i></div>
<p>Mad props for the Letterkenny reference. </p>

<div class="quote"><i>Fandyllic wrote:
Why doesn't the hidden UCP starter have non-Lua template equivalents that copy over then? This whole UCP documentation by blog comment is getting pretty tiresome.</i></div>
<p>Because it makes little sense to add them and then change them again once the functions are available. Nor do we intend to do a thorough documentation of a minor feature pre-addition via blog comment.  </p>

<div class="quote"><i> <p>This is NOT the feature complete release. We will continue to have releases which add new functionality until Phase 1 is complete and obviously continue to fix bugs throughout Phase 1 (next several months) and beyond. Release cadence will be swift. </p> </i></div>
<p>I think this may not have been clear, despite being said at the outset. As we continue to add features to the communities on the new platform, so too will we add content functions. Starter was always intentionally minimal, and used to add some basics to demonstrate how additional templates can be made and start communities off on the right foot. </p><p>The starter for the new UCP communities is in a private database. It's not accessible by outside users. Shortly before feature releases for UCP, I will add any relevant additions that capitalize on newly available tools. </p>

<div class="quote"><i>Andrewds1021 wrote:
FishTank, I don't doubt what you are saying. However, what does this have to do with the task at hand? If what you are trying to do is explain why one shouldn't have a separate caption for each image, then just say so. There is no need to hide it behind explaining the design decisions behind the tags.</i></div>
<p>Yes, that is indeed what I am saying, and it is usually important to explain the "why" when suggesting not to do something, because otherwise it frequently leads to a complete disregard. </p>

<p>As a note, Portable Infoboxes are specifically designed to avoid having a caption AND a tab title for images.  </p><p>As an explanation, for many user experiences it is important for one change (the tab, in this case) to reflect only a single response (the image, as opposed to the image + caption). Under portability and usability guidelines, this was the established rule the designers used. Therefore, the tab label is the caption, as they serve the same function: identifying what the image is, as opposed to the others in the tabbed set of images. </p><p>The "tabber" syntax inside Portable Infoboxes is actually an alias for the "gallery" function, which uses identical code underneath to create the display. The <gallery> syntax (used outside an infobox) itself only allows for a file reference and a caption. So that there are not multiple variations of the gallery syntax (which can confuse users with special cases), the simplest solution was to disallow a third parameter in a row entry. This, not coincidentally, is also in line with the point above about simplicity. </p><p>Both the user interface designers and the coding engineers agreed that this was the ideal solution. </p>

<p>The "name" field is intended to identify infobox fields or rows for logical purposes (i.e. for JavaScript or CSS targeting). The "label" field should always have a text value (even if it's in addition to the icon), for accessibility and user experience reasons. You can, in theory, use a template classified as "Infoicon" inside the label to remove the label on mobile, but for the same reasons I would suggest not doing so. </p><p>Additionally, I would strongly suggest using actual data wikitables (spreadsheet-style) on that page for usability. The "card" setup you have there is very much against guidelines for useful presentation. Sorting those items is fairly difficult, and it's not a particularly good experience on either mobile or desktop. </p>

<p>We are actually reading these. We just had no reason to dispute what Love Robin said, as it is true. </p>

<p>If you are using the CSS to change the width of smart group items elements, that's going to require using !important to override the specificity of having that width defined in the HTML element itself. </p>

<div class="quote"><i>Metro Nekusasu wrote:
Is it possible to use the new .pi-item[data-source=""]/[data-item-name=""] to style elements within smart groups?</i></div>
Yes, it is.

<div class="quote"><i>Sophiedp wrote:
Ace still has some issues tho, like the settings page, the textarea height after expanding, not highlighting everything, and changing how it highlights stuff based on if your viewing the page or editing. (tho now that I think about it idk if ace does syntaxhighlighting when you're viewing the page.)</i></div>
<p>Ace is separate from the syntax highlighter, though admittedly Ace's highlighter can not fully understand very complex code or mixed code languages (such as wikitext inside XML); these is a typical issue for code editors in general. The textarea height after expansion should be dynamic based on screen size. </p><p>I'm not familiar with the settings page you're referring to, though. Could you elaborate? </p>

<p>This was done some time ago; Firefox only now started supporting WebP, which is why you're only recently seeing a difference. </p>

<p>So, are you saying you want something like Infobox Builder for infoboxes, but with more features? </p>

<p>Be careful about personal attacks, Greenman. This is not the right place for a throwdown. </p>

<p>Try </p>

  <image source="image">
    <caption source="caption1"/>
  </image>
  <image source="image2">
    <caption source="caption2"/>
  </image>

<p>And use CSS to put the caption above the image. </p>

<div class="quote"><i>Tupka217 wrote: <p>Would those first fixes at least bring core functionality back? Or will we have to wait weeks? </p> </i></div>
<p>That's dependent on the AWB developers. Please remember that we can advise and coordinate with them, but they are ultimately responsible for their software. We don't anticipate it will be very long, but we are not in a position to declare their roadmap or provide their release schedule. </p>

<p>Neither of those specific issues has influence on AWB's not working, but we are aware that AWB is not working on some communities (namely, those on HTTPS). We are working with one of the AWB developers to resolve AWB issues with FANDOM. There are certain issues that are directly related to HTTPS that we expect can be fixed in AWB now, such as the TLS 1.2 issue (which requires .NET 4.5). Other fixes are expected in AWB 6.0, which should be released within the next few weeks. If you'd like to discuss AWB with its developers, you can drop into #autowikibrowser on Freenode. </p>

<p>https://meta.wikimedia.org/wiki/User:CharlesC/Template_for_document_links_showing_file_icons#Creating_a_document_type_template is a place to start. You can also prepend links ending with .pdf with a ::before using some fancy CSS. </p>

There you go. Fixed it for you.

<p>You're very much on the right track. ESB uses slightly different templates on the main article and transcript pages that account for the change. Namely, your Template makes the link for "Flagship (transcript)" into "Flagship (transcript) (transcript)", which is not what you want. </p>