Is there a way to do something like this
en:
name: "Jimmy"
sentence: "my name is %{name}"
this way I would be able to construct translation which are built on each other and are more dynamic so I could do
es:
name: "Inigo Montoya"
sentence: "My-o name-o es %{name}" (still working on the spanish part)
is there a way to do this?
Unfortunately, there is not a way to do this in the way you want in YAML.
See the Passing variables inside rails internationalization yml file thread for an answer to a question nearly exactly the same as yours.
Related
I have a generic test and need it to be always saved under a particular name for the given table it is running on, e.g. on table report_revenue the generated generic test name will always be diff_check_report_revenue. Right now the default dbt naming behavior for generic tests is kinda messy (it sets the test name based on the test config, which is a great idea for most cases, but unfortunately not for my particular one).
According to the docs it looks like the [alias]https://docs.getdbt.com/reference/resource-configs/alias is exactly what I need. However, I also need to set the name dynamically based on the table that is tested. I know it can be set in the yml config by setting the field alias, but I hope there might be a more elegant solution.
When I try the following:
{{
config({
"severity": 'warn',
"tags": ["diff_check"],
"alias": 'diff_check_' + {{ model | replace("XXXXXXX") | trim }}
})
}}
It just doesn't work and dbt completely ignores the alias property. model is the relation on which the test is running. It's probably just my own wrong syntax, but I'm stuck and humbly asking for advice. Thanks a lot in advance!
The docs are super confusing on test config, since they group together generic tests and singular tests, and the behavior is different.
You can use a config() block inside the definition for a generic test to configure it, and some keys (e.g., severity) work fine, but alias is not one of them.
I think alias is meant for singular tests only. To give generic tests a unique identifier (only possible since v1.1), you are supposed to use the name property (not config). Docs. Does this make sense? No. Does it make it easy for you to do what you want to do? Also no.
I'll point out that the default naming convention for a generic test includes the name of the test followed by the name of the model, but assuming that isn't good enough, your only option will be to add a name property to every test, where you define the test in the properties (fka schema.yml) file. And it looks like the name property doesn't jinja-template its value (so you can't use jinja to populate the test name). So you'll have to do a lot of this:
models:
- name: my_model
tests:
- diff_check:
name: diff_check_my_model
You could fork dbt-core. The relevant code is here.
I am using Google Cloud deployment manager to manage infrastructure as code (IAC) and they support providing schema files for describing IAC templates. Their support of jsonschema is a bit weird - the documentation is very brief but it suggests that they support the latest version of the schema plus they require title and description to be within an info object.
This is irritating because I use an HTML renderer for my schemas, which implements jsonschema and therefore, it requires title and description to be set as top-level properties.
To satisfy both, I need to duplicate, e.g.:
title: foo
description: bar
info:
title: foo
description: bar
I was hoping to just define title and description values once and then use some $ref: "#/$defs/title" magic but I don't think you can use this to dynamically set values like the title because this functionality is intended for schema parsers to fetch block content from elsewhere.
Is there any way I can avoid duplicating the values - beyond dynamically rendering my schema files which I do not want to do.
As far as I can tell, there is no way to use reference within json schema.
As a crude workaround you can use a script to add/replace placeholders:
#!/bin/bash
sed -i 's/\$title/title: foo/g' file.json
sed -i 's/\$desc/description: bar/g' file.json
My URLs have double colon on them.
I push a path to Nuxt router which has : as a part of it.
export default {
router: {
extendRoutes (routes, resolve) {
routes.push({
name: 'custom',
path: 'towns' + '(:[0-9].*)?/',
component: resolve(__dirname, 'pages/404.vue')
})
}
}
}
When I point to http://localhost:3000/towns:3 , for example, the : is translated as %3Aon the URL leading to this error message:
Expected "1" to match ":[0-9].*", but received "%3A2"
How to revert this to : ?
I tried encodeURI(), decodeURI(), encodeURIComponent() and decodeURIComponent() in vain.
A demo for the ones who wants to try: nuxt-extend-routes
Any suggestions are welcome
Vuex is using vue-router and vue-router is using path-to-regexp to parse router path configuration
It seems to me, that you are trying to use Unnamed Parameters which doesn't make sense because vue-router/vuex need the name of the parameter to pass it down to Vue component behind the route
Why don't just use named parameters ?
{
path: '/towns:id(:\\d+)',
name: 'Page 3',
component: Page3
}
Sure, result will be that $route.params.id value will be prefixed with : and all router-link params must be :XX instead of 'XX' but that's something you can deal with. vue-router (path-to-regexp) is using : to "mark" named path parameters ...there's no way around it
You can take a look at this sandbox. Its not Nuxt but I'm pretty sure it will work in Nuxt same way....
Update
Well it really doesn't work in Nuxt. It seems Nuxt is for some reason applying encodeURIComponent() on matched path segments and throws an error. It works when server-side rendering tho (it throws some error on client still)...
Firstly, I concur with Michal Levý's answer that there's a library bug here. The line throwing the error is here in the Nuxt source:
https://github.com/nuxt/nuxt.js/blob/112d836e6ebbf1bd0fbde3d7c006d4d88577aadf/packages/vue-app/template/utils.js#L523
You'll notice that a few lines up the segment is encoded, leading to : switching to %3A.
However, this line appears to have originated from path-to-regexp:
https://github.com/pillarjs/path-to-regexp/blob/v1.7.0/index.js#L212
It isn't trivial to fix this bug because the encoding is not simply 'wrong'. There's a lot of stuff going on here and by the time that line is reached the parameter values have been URL decoded from their original values. In the case of our unencoded : that causes problems but in other cases, such as matching %3A, the encoding would be required.
The handling of encoding within path-to-regexp is a delicate topic and we aren't helped by the old version being used. This also makes it more difficult to come up with a suitable workaround in your application.
So, let's see what we can do...
To start with, let's consider the path:
path: 'towns' + '(:[0-9].*)?/',
Bit odd to concatenate the strings like that, so I'm going to combine them:
path: 'towns(:[0-9].*)?/',
The / on the end isn't hurting but it seems to be unnecessary noise for the purposes of this question so I'm going to drop it.
On the flip side, not having a / at the start can cause major problems so I'm going to add one in.
The .* is suspicious too. Do you really mean match anything? e.g. The current route will match towns:3abcd. Is that really what you want? My suspicion is that you want to match just digits. e.g. towns:3214. For that I've used [0-9]+.
That leaves us with this:
path: '/towns(:[0-9]+)?',
Now, the : problem.
In general, route paths are used in both directions: to match/parse the URL and to build the URL. Your use of an unnamed parameter makes me wonder whether you only intend to use this route for matching purposes.
One option might be this:
path: '/towns:([0-9]+)',
By moving the : outside the parameter it dodges the encoding problem.
There are two problems with the code above:
The colon/number suffix is no longer optional on the URL. i.e. It won't match the path /towns as the original route did. This can be solved by registering /towns as a separate route. I'm not aware of any other way to solve this problem with the available version of path-to-regexp.
You won't be able to use it to build URLs, e.g. with nuxt-link.
If you need to be able to use it to build URLs too then you could use a named parameter instead:
path: '/towns::town([0-9]+)',
The :: part here is potentially confusing. The first : is treated literally whereas the second : is used as a prefix for the town parameter. You might then use that with nuxt-link like this:
<NuxtLink :to="{ name: 'custom', params: { town: 4 } }">
...
</NuxtLink>
We would like to adjust the meta keywords of a web page based upon the specific action. As a novice at haml, is there a way that this could be done via a provides statement. For example:
in client.html.haml
- provide(:keywords, 'here are unique keywords')
and in our application.html.haml, how would we do this? Like:
%meta{ name: "keywords", content: #{yield(:keywords)} ||= default keywords
but this doesn't work.
You don't say why your approach doesn't work, so I'm going to guess it's a syntax error in your haml (missing closing bracket). Also, I'm not sure what default keywords is or why you're using the ||= operator - either of those may also be causing your solution to "not work".
Something like the following will work as expected:
# application.html.haml
%meta{ name: "keywords", |
content: content_for?(:keywords) ? yield(:keywords) : "default" }
# this could also be achieved using content_for?(:keywords) || "default"
# client.html.haml
- provide :keywords do
this should work
After some time I spent staring at the jbake code, I figured out that if I declare my own property in jbake.properties :
...
foo=bar
...
I can reuse that in files that go through a template engine by referencing it as ${config.foo}. I'd like to have this substitution working also on the content lvl, i.e. for files written in asciidoc, living inside the content directory.
Is there any non-trivial way to achieve it? How can I make the templating engine to proccess the result of asciidoc parses engine, or make it running it before the asciidoctor?
I found the answer myself.
To use the property substitution in asciidoc files, add following to the jbake.properties:
...
asciidoctor.attributes.export=true
foo=world
...
and reference the variable in aFile.adoc this way:
Hello {foo}!