Is there any way to build properly webpack bundles with different languages, like i18n-webpack-plugin, but supporting plural forms? Something like gettext.
For example:
1 girl - 1 dívka
2 girls - 2 dívky
10 girls - 10 dívek
You can try this library:
https://www.npmjs.com/package/jed-webpack-plugin
It helps you to make multiple bundles for each language.
Related
In our company, we are building a chatbot using Microsoft Luis Bot Framework. For two of the intent's, I don't know how I should annotate the examples.
I have a product called ABC and I need two different intent's: Access ABC and Use ABC. That is, for each of these two intents, we have different answers.
Now, my questions is how can I define synonyms for verbs. Should I define verbs as entities?
Our utterances for the intent Access ABC would be like:
1) How can I access ABC?
2) How can I reach ABC?
Our utterance's for the intent Use ABC would be like:
3) How can I use ABC?
4) Is there any introduction to ABC?
5) I am new to ABC. Is there any usage guideline?
The problem that I see is that if I don't tag the verbs for the first intent, how can the system distinguish between 1 (or 2) and 4?
This is a big problem. In your utterences 1 and 2 for example, all you are teaching a model is that the verb access all the verb reach have no importance. this is because you are telling the models look at those two sentences both works regardless of what is a verb. This mean it will create quite a lot of confusions with your sentence number three. Training this model is still very empirical. We use QBox (disclaimer, I work for them). Having a couple of verbs uterences for each use case might work but you are going to have to try it. But be careful at your training examples. Try to vary as much as you can the word that play less importance.
1- how can I access ABC
2- tell me how to reach ABC
3- I can't access ABC
4- I'm struggling to reach ABC
remember that you will need 10 to 15 examples minimum in order to reach a good level of performance. This depends of the number of intents you have in your model of course
1. Can I use constants in config.yaml files?
Here's a old, closed feature request: https://forge.typo3.org/issues/81593
2. What's the best way to realize little differences in routing config.yaml files?
For Example:
rootPageId: <DEV-ID>
rootPageId: <PROD-ID>
With Typoscript this where easy with constants:
rootPageId: {$mainTemplate.rootPageId}
3. Why is it not possible to use the much better and more flexible TypoScript to do the routing-config with TYPO3 LTS-9?
4. Is there a "Backend yaml-Object-Browser" similar to the very good "TypoScript-Object Browser"?
ad 1) https://docs.typo3.org/m/typo3/reference-coreapi/9.5/en-us/ApiOverview/SiteHandling/UsingEnvVars.html might be the direction you want to follow
ad 2) why should a rootPageId differ by context? Perhaps the domain could/should differ, but the IDs should probably be the same, example: https://docs.typo3.org/m/typo3/reference-coreapi/9.5/en-us/ApiOverview/SiteHandling/BaseVariants.html
ad 3) I don't understand why a "why" is interesting - You can propose a feature request. However from my experience I didn't ever see a need for that. It is the other way around, probably you want to get site config from TypoScript: https://docs.typo3.org/m/typo3/reference-coreapi/9.5/en-us/ApiOverview/SiteHandling/UseSiteInTypoScript.html
ad 4) That one and UserTSconfig have no browser/viewer atm. Although it shouldn't be hard to implement one.
I have the site running on 3 languages, my component should be able to show translated items of my component
realestates
--realestate(items) - en-EN
--realestate(items) - de-DE
--realestate(items) - fa-FA
Would a good workaround be to extend my items table with a column translation which keeps the translation language code and each time the query would take this into consideration? For example:
select * item from realestets where translation = 'en-EN'
or there is a better way to do this?
You could try following the same procedure Joomla is using for multilingual content. components/com_content/helpers/association.php might be a good starting point.
Joomla adds associations in the #__associations - table, where you can look up items with a multilingual counterpart.
Magento is a pretty complex application. And knowing as a large open source ecommerce platform. Throughout Magento 1 architecture, it commonly used 12 design patterns which allows developers to view and use them in real.
As you know, Magento 2 is coming soon. I want to know what patterns are approved? And give us some examples?
Composite Pattern
Strategy Pattern
Factory Method Pattern
Observer Pattern
Object Manager (which consist of 11+ Design Patterns)
Decorator Pattern
Proxy Pattern
I think that the best solution for you is take a look into Magento 2 documentation and source code.
This question already has an answer here:
Which plugins/gems should I use to dynamically generate thumbnails on-the-fly in Rails 3?
(1 answer)
Closed 9 years ago.
Is there any gem that allows you to generate automatic thumbnails with basic info in the frontpage?
Sites like indiegogo and kickstarter have thumbnails in groups of 3 or 4 per row. Each one represent a recent post. I am trying to do something like that.
I am a ruby noobie and would also give it a try if somebody explain me how to get this done with or without a gem. I could work with ruby or javascript.
Basically the point is to create posts and have them displayed as thumbnails in the index, in groups of 3.
Thanks!
Will the content come from your app? If yes, then I reckon you are looking for a way to layout your list of objects like how they did it in kickstarter and indiegogo. There are different libraries that you can use. Here are some of the libraries which you can use:
masonry: http://masonry.desandro.com/
isotope: https://github.com/desandro/isotope
packery: http://packery.metafizzy.co/
These libraries will help you to create brick / grid layouts.
Or, do you want to create previews from links? Then maybe this gem can help you as well: https://github.com/gottfrois/link_thumbnailer
Hope this helps!