647121d13e
Note that, currently, we take these settings from the database but we
don't provide a way to edit them through the admin interface, so the
locales must be manually introduced through a Rails console.
While we did consider using a comma-separated list, we're using spaces
in order to be consistent with the way we store the allowed content
types settings.
The `enabled_locales` nomenclature, which contrasts with
`available_locales`, is probably subconsciously based on similar
patterns like the one Nginx uses to enable sites.
Note that we aren't using `Setting.enabled_locales` in the globalize
initializer when setting the fallbacks. This means the following test
(which we could add to the shared globalizable examples) would fail:
```
it "Falls back to an enabled locale if the fallback is not enabled" do
Setting["locales.default"] = "en"
Setting["locales.enabled"] = "fr en"
allow(I18n.fallbacks).to receive(:[]).and_return([:fr, :es])
Globalize.set_fallbacks_to_all_available_locales
I18n.with_locale(:fr) do
expect(record.send(attribute)).to eq "In English"
end
end
```
The reason is that the code making this test pass could be:
```
def Globalize.set_fallbacks_to_all_available_locales
Globalize.fallbacks = I18n.available_locales.index_with do |locale|
((I18n.fallbacks[locale] & Setting.enabled_locales) + Setting.enabled_locales).uniq
end
end
```
However, this would make it impossible to run `rake db:migrate` on new
applications because the initializer would try to load the `Setting`
model but the `settings` table wouldn't exist at that point.
Besides, this is a really rare case that IMHO we don't need to support.
For this scenario, an installation would have to enable a locale, create
records with contents in that locale, then disable that locale and have
that locale as a fallback for a language where content for that record
wasn't created. If that happened, it would be solved by creating content
for that record in every enabled language.
CONSUL DEMOCRACY
Citizen Participation and Open Government Application
This is the opensource code repository of the eParticipation website CONSUL DEMOCRACY, originally developed for the Madrid City government eParticipation website, and currently maintained by the open source software community in collaboration with the CONSUL DEMOCRACY Foundation.
Documentation
Check the ongoing documentation to learn more about how to start your own CONSUL DEMOCRACY fork, install it, customize it and learn to use it as an administrator/maintainer.
CONSUL DEMOCRACY Foundation and project website
You can access the main website of the project at http://consuldemocracy.org where you can find information about the use of the platform, the CONSUL DEMOCRACY Foundation, the global community of users and local partners, news, and ways to get more support or get in touch.
Configuration for development and test environments
NOTE: For more detailed instructions check the docs
Prerequisites: install git, Ruby 3.2.3, CMake, pkg-config, shared-mime-info, Node.js 18.18.2 and PostgreSQL (>=9.5).
git clone https://github.com/consuldemocracy/consuldemocracy.git
cd consuldemocracy
bin/setup
bin/rake db:dev_seed
Run the app locally:
bin/rails s
Run the tests with:
bin/rspec
You can use the default admin user from the seeds file:
user: admin@consul.dev pass: 12345678
But for some actions like voting, you will need a verified user, the seeds file also includes one:
user: verified@consul.dev pass: 12345678
Configuration for production environments
See installer
Current state
Development started on 2015 July 15th. Code was deployed to production on 2015 september 7th to decide.madrid.es. Since then new features are added often. You can take a look at the current features at the project's website and future features at the Roadmap and open issues list.
License
Code published under AFFERO GPL v3 (see LICENSE-AGPLv3.txt)
Contributions
See CONTRIBUTING.md