constants_config.yaml
site: fb
another_site: google
my_config.yaml
my_site: ${constants_config.yaml]
Resulting my_config.yaml
my_site: fb
I just want to get a single constant, not the whole constants_config.yaml (which is done by using default)
Not possible directly.
You can do it with interpolation into a constants node.
Something like:
constants.yaml:
constants:
site: fb
another_site: google
main.yaml:
defaults:
- constants
my_site: ${constants.site}
The composed config should look something like:
constants:
site: fb
another_site: google
my_site: ${constants.site}
Related
Let's say I have this basic app:
from dataclasses import dataclass
import hydra
from hydra.core.config_store import ConfigStore
#dataclass
class MyAppConfig:
req_int: int
opt_str: str = "Default String"
opt_float: float = 3.14
cs = ConfigStore.instance()
# Registering the Config class with the name 'config'.
cs.store(name="base_config", node=MyAppConfig)
#hydra.main(version_base=None, config_name="base_config", config_path="conf")
def my_app(cfg: MyAppConfig) -> None:
print(cfg)
if __name__ == "__main__":
my_app()
Is it possible for the user to be able to call my app like this:
python my_app.py req_int=42 --config="~/path/to/user-defined-config.yaml"
And user-defined-config.yaml would contain only this:
opt_str: User Config String
The output should look like this:
{'req_int': 42, 'opt_str': 'User Config String', 'opt_float': 3.14, 'config': 'hydra-user-conf'}
The closest I got to that is:
user-defined-config.yaml
defaults:
- base_config
- _self_
opt_str: User Config String
And the invocation:
python hydra/app.py req_int=42 --config-path='~/path/to' --config-name="hydra-user-conf"
But this way the user (who I don't want to require to be familiar with hydra) has to specify the path to their config file via two cli arguments and also include the defaults section in their config, which would be redundant boilerplate to them if they have to always include it in all of their configuration files.
Is this the closest I can get with hydra to the desired interface?
One thing you can do is to pre-configure the config searchpath in the primary config. Adding something like ~/.my_app/ to your config searchpath (thus potentially eliminating the need for --config-path|-cp.
In yaml it would look like:
hydra:
searchpath:
- file://${oc.env:HOME}/.my_app
Another thing to consider is having the app generating an initial config for the user on demand. I took this approach with Configen.
In general, the current patterns are not amazing and maybe there is room for some improvements in Hydra to make this more ergonomic (You can open a discussion about it).
I created a Firebase Deep Link for my Flutter app to open the app after the registration process was successful. The link looks like the following:
https://myLinkDomain.page.link/routeName/
During the registration process, a parameter must be appended to the end of the link, which I must read out in the app for successful completion.
The problem is that if I append the parameter to the end of the link, I can no longer access it. The link in this case looked like this:
https://myLinkDomain.page.link/routeName/?myCustomParam=myValue
If the parameter is given in the middle of the link, I can use it in the app. Like this:
https://myLinkDomain.page.link/routeName/?myCustomParam=myValue&apn=someStuff&isi=someStuff&ibi=someStuff&ifl=someStuff
However, the registration process requires that the parameter be added to the end of the link.
Is there a way to build the Firebase Deep Link so that the parameter can be added at the end and still be recognised in the app?
Thanks for any help!
No matter when this parameter goes - at start or at the end of the line.
I had the same problem with passing some custom parameters to my app.
Here is we should start with manual url construction:
firebase manual link construction
I have no easy way to pass parameters, so I just change the link parameter body to put here more parameters:
https://example.page.link/?link=https://example.com/?route%3Dprofile%26param1%3DA%26param2%3DB&apn=some&isi=some&ibi=some
prefix: https://redecor.page.link/
main body in link parameter (should be encoded). There is the place for all needed parameters you want to pass (route=profile¶m1=A¶m2=B) - all parameters should be encoded!
encoded should be like this: route%3Dprofile%26param1%3DA%26param2%3DB
other parameters (what are they means you could read here) for firebase proposes (no needs to encode):
apn=some&isi=some&ibi=some
Never mind. The solution is to change the order of the url parameters: myLinkDomain.page.link/routeName/…
I was wondering if it is possible with Symfony 3.5 to use multiple translation files for a single language when using yml files.
Currently I have something like this:
AppBundle/Resources/translations/messages.en.yml
AppBundle/Resources/translations/messages.de.yml
which contains all my translations in either language. However I was wondering if it was possible to change this to the following structure:
AppBundle/Resources/translations/en/products.yml
AppBundle/Resources/translations/en/invoices.yml
AppBundle/Resources/translations/de/products.yml
AppBundle/Resources/translations/de/invoices.yml
I have been looking but I have been unable to find some kind of solution for this. I got it working for splitting up my routes.
AppBundle/Resources/config/routing.yml
appbundle_routes:
resource: '#AppBundle/Resources/config/routing'
type: directory
Inside that folder I got all my routes split like:
AppBundle/Resources/config/routing/products.yml
AppBundle/Resources/config/routing/users.yml
AppBundle/Resources/config/routing/invoices.yml
I was wondering if it was possible to achieve the same thing with translations?
Symfony's Translator requires files to by named in format domain.locale.loader. In case you have messages.en.yml:
messages is the default name of domain, you can also specify eg. invoices
en is the locale
yml is specifying YAML loader will be used
So your proposed use is not possible to achieve with standard set of configs and functionality. However, you can split your translations to different domain files. So paths would be:
AppBundle/Resources/translations/products.en.yml
AppBundle/Resources/translations/invoices.en.yml
And when you are using translator you specify the domain in which the translation should be looked for:
$translator->trans('translated.key', [], 'invoices');
Or in Twig:
{{ 'translated.key'|trans({},'invoices') }}
I need to change the name of the route when I change the language. For example, I have a route /en/career but when I change to Czech language, I need a route /cs/kariera. Basically I need the URLs to be localized. Right now, when I'm on /en/career and change language to cs, I get /cs/career. This page should not exist at all and when I render the page on server, I correctly get 404. Can I do something like this with next-i18next package? If so, how?
I found this package https://github.com/vonschau/next-routes-with-locale which probably does exactly what I need but it's apparently no longer maintained and doesn't work under next.js 8.
What I did eventually was to use next-routes package and defined specific route for every page, such as:
module.exports = routes()
.add('en-career-listing', '/en/career/:listing', 'career/listing')
.add('cs-career-listing', '/cs/kariera/:listing', 'career/listing')
.add('en-career', '/en/career', 'career')
.add('cs-career', '/cs/kariera', 'career')
.add('en-our-story', '/en/our-story', 'our-story')
.add('cs-our-story', '/cs/nas-pribeh', 'our-story')
And I also had to create a custom Link component based on next/link where I manually added the language to URL.
next-i18next supports this functionality, it called locale subpaths.
You need to configure: new NextI18Next({ localeSubpaths: 'foreign' }), and then use the Link & Router that NextI18Next instance has on it, not the next/router.
I'm using JMSI18nRoutingBundle for locale routing on our new site, but our existing site uses language + country in the following format and I need to keep the URLs looking the same.
example.com/us/en/hello (en_US)
example.com/be/fr/bonjour (fr_BE)
Is there any way to do this using config? If not, where is the best place to start customizing?
It doesn't look it's possible to do through config, but it can be done by replacing default implementation of PatternGenerationStrategyInterface by your own implementation.
You can check out default implementation that bundle uses here.
After you create your own implementation, just make bundle use your own implementation by setting the config parameter. If you're using YAML for example:
parameters:
jms_i18n_routing.pattern_generation_strategy.class: YourBundle\YourImplementationClass
Hint: you can basically copy/paste from default implementation and change line 69 to use str_replace('_', '/', $locale) instead of just $locale. That way, newly generated route pattern will contain a / if locale contains an _.
Not very elegant solution, but bundle unfortunately doesn't provide enough configuration to make it prettier.