In Rails 4 (which supports multilingual inflections), I can set:
config.i18n.default_locale = :es
in my config/application.rb, which allows me to do stuff like this in the console:
'general'.pluralize(:es) => "generales"
But when I run:
rails g model General conciencia:string atencion:string
Rails generates files with 'general' pluralized as 'generals' which in spanish should be 'generales'
Shouldn't Rails be using the multilingual inflector for its generators if the locale is set? Is there a way to force it to use them?
Thanks!
A bit late, but for the record: There's an argument in a Rails issue about why is it this way (so it's no a bug, but you can discuss it about):
Source: https://github.com/rails/rails/issues/10125#issuecomment-17274499
Up to Rails 4, the inflector had no support for multiple locales.
There was only one set of rules. The application has a default locale,
and in a i18n application each request may have a different locale,
but that didn't affect the inflector.
The inflector is not only used by the application, it is also used by
the framework to convert paths to class names, class names to tables,
create method names dynamically for the associations API, etc.
Obviously, those computations cannot vary. If your schema has a
"regions" table, Active Record has to map the Region class always to
the "regions" table, no matter the evolution of the application
(unless the schema changes, but the schema has to be visualized as
mostly static regarding to this, much more static that a configuration
option).
I have worked on applications that started development using :en, get
i18ned, and then switch to a default locale of :es. The locale is
something that affects the interface in that mindset. Everything
internal should work as it did before.
You should be able to change the default locale and everything else in
a way that does not affect static things like association names,
tables, routes, etc.
In could be the case that you have i18n routes (which change with the
locale of the request), but in general the statement above should be
true.
In order to be as backwards compatible as possible, we have left the
framework untouched, and have made the inflections to have a default
of :en so that existing applications get the same mappings after an
upgrade.
Related
I'm new to mobile development and plan to build an app using plain HTML & jQuery, with Onsen UI.
I read that we can use localForage as a database and have a few questions.
Is it mandatory to have a database name for my app. If no, then other apps in mobile may also be using localForage. Will the DB be same then for all apps.
The document here says, config should be called before each action.
So, is it ok if it is initialized on page load like this:
$(document).ready(function(){
localforage.config({
name : 'myApp',
version : 1.0,
storeName : 'keyvaluepairs'
});
});
or should it be declared before each action (get, set, clear etc.)
How can we know that the action is triggering the desired database, as it is not specified in the action methods.
Is it mandatory to have a store name.
Is it mandatory to have a database name for my app. If no, then other apps in mobile may also be using localForage. Will the DB be same then for all apps.
A: Yes and no. It is in fact mandatory to have a database name. However if you leave it unset, the default value "localforage" is used.
The document here says, config should be called before each action. So, is it ok if it is initialized on page load like this ...
A: Yes, it totally fine to init in $(document).ready(cb). In fact it's fine to "initialize" at any time, as long as you make sure it happens before the first ever call to any real action (setItem/getItem, etc.).
How can we know that the action is triggering the desired database, as it is not specified in the action methods.
A: localforage can have multiple instances, whereas each instance is bound to only one database, (more precisely, it's bound to a specific store of that specific database). You know the action is targeting a specific database, because these actions are methods of a specific instance. No ambiguity here.
I personally suggest you name your instance explicitly:
var myAppDb = localforage.createInstance({
// these are the same options accepted by localforage.config()
name: 'myApp',
version : 1.0,
storeName : 'keyvaluepairs'
});
myAppDb.setItem('foo', 'bar');
This way you're 100% sure the action is fired on "myApp" database ;-)
Is it mandatory to have a store name.
Again, yes and no. But wait, hear me out, this one is a bit tricky.
Whereas the default database is actually named "localforage", store in localforage has this strange internal concept of un-named default store. I personally find it very confusing. And it behaves quite quirky when you use LOCALSTORAGE as driver.
So the rule of thumb is always name your store. Just treat it like mandatory. If you have only one store in one database, maybe name it "default". Sound better than "keyvaluepairs" don't you think?
let instance = localforage.createInstance({
driver : localforage.INDEXEDDB, // Force WebSQL; same as using setDriver()
name : name,
version : 1.0,
size : 4980736, // Size of database, in bytes. WebSQL-only for now.
storeName : 'YourStoreName', // Should be alphanumeric, with underscores.
description : 'Your Description'
});
instance.setItem("key", {"name":"abc"});
**You can set config from createInstance as well **
I need to change short month in moment.
But I can't do it.
I have try to set
localeOutputPath: 'assets/moment-locales'
And call
Ember.$.getScript('/assets/moment-locales/ru.js');
In this case i have ember-mirage error
Your Ember app tried to GET '/assets/moment-locales/ru.js?_=1490191145335',
but there was no route defined to handle this request. Define a route that
matches this path in your mirage/config.js file
Is it simple way to set short months name for moment?
I assume you are using ember-moment addon; and already have configured config/environment.js with
moment: {
// This will output _all_ locale scripts to assets/moment-locales
localeOutputPath: 'assets/moment-locales'
},
as you have mentioned.
Ember.$.getScript('/assets/moment-locales/ru.js');
provides a way to dynamically load moment ru locale on the fly when needed. This means instead of including the related locale to your application's javascript file you prefer to load relevant locale upon some user request in your application. Generally it is best to perform such loading operation within a router's hook methods such as beforeModel or model.
In order to get short month names from moment; you need to first import ES6 moment module via
import moment from 'moment';
and access the short month names with
moment.monthsShort()
As far as I can see; there is a problem with the way you are requesting the locale so you are getting the error you have mentioned. I believe a working code is a better explanation from pure text; hence I have created the following git repository to illustrate how you can change the locale dynamically in a route and how you can display short names retrieved from moment. Please take a look at it by cloning and running in your localhost.
In the application at this repository, application.hbs contains links to 5 sub-routes; each displaying short names of months in different languages. The code that does the trick of dynamically loading the relevant locale is in routes/locale-route.js file's model hook method. If locale is already loaded (note that English is included by default with moment) it simply returns the short names of the months via switching to target locale (moment.locale(localeToLoad);). Otherwise, it performs a remote call to the server and waits for the response (by using a promise) to return the name of months. All routes for 5 different languages extend from this base route. Once, a locale is loaded from the server; you no longer need to load it again once more and the locale-route already handles it as I explained. I hope that helps.
After reading your comment; I updated the source code to include ember-cli-mirage. Mirage is a client-side mock server to develop, test and prototype your application. Once you include it as a dependency it starts intercepting your remote call requests. Hence, in your case mirage intercepts requests for demanding related locale. What you need to do is passing through mirage for locales. In order to do that, you need to add following
this.passthrough('/assets/moment-locales/**');
to mirage/config.js so that mirage will not interfere with demanding moment-locales at the runtime. Please see related file under the git repository I have provided. This will solve your problem for sure.
Symfony uses a set of coding standards to set out for us how to program and what style we should use. My question is short and simple. I would like to know if symfony (together with doctrine ORM) has a similiar set of standards when it comes to building and structuring my database.
For example:
Should I use Camel Case?
Should my table name be user or users
Do I use capitals?
What charset is recommanded?
Basically, you do not need to care about database naming as Doctrine will do everything for you.
You should use Doctrine cli commands to generate your database schema based on your entities, or even better use Doctrine Migrations to maintain changes.
Should I use Camel Case?
For entity class names, I'd recommend sticking with PSR, so yes, use CamelCase.
Symfony by default uses underscore naming strategy, so entity CamelCase will be generated as table camel_case (if not manually overriden).
You can set another naming strategy, but the default underscore strategy is a fine choice.
Should my table name be user or users
user is a ANSI SQL reserved word, so I recommend using users. Or, if you prefer having entities in singular, try person instead.
Do I use capitals?
Again, Doctrine naming strategy will solve this for you. Moreover, eg postresql converts all table names and such identifiers to lowercase, so using capitals explicitly can cause problems.
What charset is recommanded?
Use UTF-8 (or more specifically utf8mb4 if needed). There are few reasons to use any other.
I'm building a CiviCRM extension, which would also have an admin section with UI for setting various configuration specific to the extension. I'm looking for a recommended approach for storing the configuration in the database.
One way is to create a new table in the database specifically for this purpose, but this seems like an overkill if there are only a couple of options to be saved.
Another way could be to use the civicrm_setting table, which kind of makes sense at first, but I'm not sure if this table is meant to be used for this purpose.
Any advice would be appreciated.
Yes, you can and should definitively use civicrm_setting.
civicrm_setting has a column group_name that should contain a unique identifier for your extension. I usually put the full name of the extension, like org.example.extension but it could be any string, and in core they use label name (e.g., Preference settings).
To interact with those settings, you can do the following :
// save the setting
CRM_Core_BAO_Setting::setItem($value, 'My group name', 'my_setting_name');
// get the setting
$setting = CRM_Core_BAO_Setting::getItem('My group name', 'my_setting_name');
// get all the setting for you extension
$settings = CRM_Core_BAO_Setting::getItem('My group name');
There seems to be an API for Setting but it doesn't seem to work well in CiviCRM 4.4.x. Don't know if it is better in CiviCRM 4.5.
What you could also do (our current practice) is store your configuration logic in a special class using the singleton pattern (as CiviCRM does itslef). If you want to see an example check this:
https://github.com/CiviCooP/no.maf.oppgavexml/blob/master/CRM/Oppgavexml/Config.php
I am working on a django website/project, it has already been internationalised/localised to us-english, gb-english and mandarin.
It is deployed with same codebase except for the settings config which states what lang to use. Some deployments are mandarin only, others are us-english.
The client now has a requirement to change some of the language used within a gb-english version for a specific deployment. My main goal is not to duplicate things and I think I can get what I need out of django 18n.
Basically, I am looking to find if i can or should use django i18n to handle:
'Welcome' on deployA
'Oh hai' on deployB,
even though they're still both gb-english based sites, I feel I should be able to say that deployA will use 'en_GB' and deployB would use 'en_GB_special'.
I suppose it's the fact that I want to use a non-standard i18n name/code that is making me wonder if I should do this, or if I am approaching this in the wrong manner.
I would only create a new language if you're intending to maintain two translations. If the new site will need to stay in sync with en_GB and/or you intend to use the customization in another language then I think you'd be better off creating new messages, adding a string for them to en_GB and add a flag to your application to switch the feature for your feline client.