Until only a few minutes ago I was using this syntax to translate a select element, and then I found out that these strings (contents of the <option/> elements) are not being captured in the generation of the .pot file, therefore not being added to the strings for translation list.
<select name="sel1">
<option i18n:translate="all">All</option>
<option i18n:translate="new_releases">New Releases</option>
</select>
I am running versions Pyramid 1.5.2, Lingua 3.9, Babel 1.3
What should be the correct way to translate these <option/> elements?
The problem here (after talking about this on irc) is the command used to extract messages from a template: you are using Babel's update_catalog command. This is no longer support in current versions of lingua: lingua now has its own extraction framework. That means you need to use lingua's pot-create command instead.
The lingua documentation explains why lingua no longer uses Babel, and has documentation and examples for using pot-create.
Related
I know there's already a question on converting line breaks to <br> tags in Thymeleaf, but the "#strings.replace" solution from there, relies on getting the line.separator system property to make it platform neutral. Since Thymeleaf 3.0.12 this is now broken (see this GitHub issue) when used with th:utext. Is there a recommended replacement for this, other than just using "\n"? For reference, the current line (which we use all over our codebase) looks something like this:
<div th:utext="*{#strings.replace(#strings.escapeXml(fieldName),T(java.lang.System).getProperty('line.separator'),'<br>')}">
I made a Thymeleaf dialect that makes it easy to keep the line breaks, if the css white-space property isn't an option. It also bring support for BBCode if you want it. You can either import it as a dependency (it's very light) or just use it as inspiration to make your own. Check it out here : https://github.com/oxayotl/meikik-project
I just installed Saxonc Python API. All the examples work fine. However, every time I try to evaluate my own expressions, the XPath processor returns an empty sequence. I tested the expressions using Oxygen, and it works well and selects the right node under Xpath 2.0. I think the issue may be that by default, the Xpath processor uses Xpath version 1.0.
Saxonc Python API documentation says that:
Saxon/C provides processing in XSLT 3.0, XQuery 3.0/3.1 and XPath 2.0/3.0/3.1, and Schema validation 1.0/1.1.
However, I can't find how to change the Xpath version.
I have seen some codes used in smarty like [-php-] [-/php-]. I wonder what version of smarty used these kind of syntax. I have seen some other syntax also like {php} {/php}.
Version 2 and up (not sure about previous versions) of Smarty allows you to change the delimiters used, so i.e. you can use {tag}, {{tag}}, [-tag-], [[tag]], etc... you can even use different types of opening and closing delimiters (i.e. "{tag]]")
By that, I mean the built-in bash string operators ${lowercase^^} and ${uppercase,,}. I just wondered what the minimum version is that supports it. Googling indicates version 4.x. But what is version .x? Version 4.3.1 or 4.0?
There doesn't seem to be a change log on http://www.gnu.org/software/bash/
It's added in 4.0. See the NEWS file in Bash source code:
This is a terse description of the new features added to bash-4.0 since
the release of bash-3.2. As always, the manual page (doc/bash.1) is
the place to look for complete descriptions
... ...
hh. There are new case-modifying word expansions: uppercase (^[^]) and
lowercase (,[,]). They can work on either the first character or
array element, or globally. They accept an optional shell pattern
that determines which characters to modify. There is an optionally-
configured feature to include capitalization operators.
I'm updating codes to use MSXML6.0 from MSXML3.0.
However, I noticed that, for MSXML3.0, the default "SelectionLanguage" is "XSL Pattern", while MSXML6.0 only support XPath.
I have concerns that this change would introduce differences in the query syntax.
Can somebody list the difference of syntax between these two syntax?
The one thing that has tripped me up is selecting the first node in a node set. For example, we'd been using MSXML 3.0 (which uses XSLPattern) and has queries like this:
/root/book[0]
This query was supposed to select the first book. This works with XSLPattern. But with XPath, this is correct:
/root/book[1]
So when I switched us to using MSXML 6.0, which uses correct XPath, all those queries with "[0]" stopped working.
Update:
I just found this link that talks some more about XSLPattern and XPath:
MSDN Magazine: MSXML 3.0 Supports XPath 1.0, XSLT 1.0, XDR, and SAX2
http://msdn.microsoft.com/en-us/magazine/cc302348.aspx
Update #2:
Here's the W3C Spec on XSLT which includes XSL Patterns:
http://www.w3.org/TR/1998/WD-xsl-19981216.html#AEN376
Update #3
Here's another post that describes the same thing I mentioned above:
http://www.eggheadcafe.com/software/aspnet/29579789/xml-parsing.aspx
XSL Pattern, if I remember correctly, was a selection language like XPath but was implemented by Microsoft before XPath was standardised (possibly even created). I don't think anyone even has anything that documents XSL Pattern any more. You can basically forget about it and concentrate on XPath. It has the same purpose but is supported and standardised.
XSL Patterns appear to be part of WD-XSL, "working draft XSL", which means versions predating the XSL recommendation (1999), which differ significantly from the final 1.0 version.
Microsoft has the relevant info on "XSL Patterns". Here's a quote from the section XPath 1.0 APIs:
MSXML 2.0 provides support for XSL Patterns, the precursor to XPath 1.0. The notion of an XML addressing language was introduced into the original W3C XSL Working Drafts (http://www.w3.org/TR/1998/WD-xsl-19981216.html) and called XSL Patterns. MSXML 2.0 implements the XSL Patterns language as described in the original XSL specification with a few minor exceptions.
MSXML 3.0 provides support for the legacy XSL Patterns syntax as well as XPath 1.0.
XPath, in my experience, is much easier to get your head around. I avoid XSL like the plague if I can. But you are right, the syntax is very different, so if you want to switch from XSL to XPath you have some work ahead of you. I cannot explain the differences easily, but this tutorial should give you some idea of what XPath is about:
http://www.w3schools.com/XPath/xpath_examples.asp