We accidentally removed the `count` option in commit 55fb14ac, which
made the translation return a hash.
The test is a bit hacky, which makes me think changing the user
interface would probably be a better solution.
Internet Explorer 9 was released eight years ago. Besides that, we don't
really support IE8 anyway, since we show a popup to IE8 users saying
we don't support it, we haven't maintained the IE8-specific CSS file for
years, and we don't test our JavaScript against IE8.
We're reading the value from the database, but the
`ApplicationMailer.default` method is evaluated when the application is
started. So if we don't use a Proc, we'll need to restart the server
every time we change the value in the database, or else the old value
will still be used.
Using a Proc makes sure the mailer from address is evaluated at runtime,
so emails are sent using the from address currently defined in the
database.
The same situation took place using the devise mailer. Now we don't need
to check for the settings table being present because the Proc in the
devise initializer won't be evaluated before the settings table is
created and populated.
The label text was always in English, and it wasn't associated with any
input field.
The `SecureRandom` part is a quick hack so we don't get duplicate IDs.
Using "your_answer_#{question.id}" might work as well, but right now I'm
not sure if the form is sometimes rendered twice for the same question.
The line:
```
config.i18n.load_path += Dir[Rails.root.join("config", "locales", "**", "*.{rb,yml}")]
```
Was adding every locale under the `config/locales` folder, including the
ones inside `config/locales/custom/`. The files were loaded in the same
order as listed using `ls -f`.
So if the custom locales were loaded before the folder
`config/locales/#{I18n.locale}`, the default locales would override the
custom ones, and we want the custom locales to override the default
ones so CONSUL is easier to customize.
- Add new translations on SignatureSheet show page.
Changes:
-> "document number" to "sigantures"
-> "documents" to "users"
- Remove unused translations from the others yml
- Display help text and example text according to
remote census configuration:
Examples with expecte results:
* With remote census without :date_of_birth and :postal_code:
-> "To verify a user, your application needs: Document number"
-> "Required fields for each user must be separated by commas and
each user must be separated by semicolons."
-> "Example: 12345678Z; 87654321Y"
* With remote census with :date_of_birth required:
-> "To verify a user, your application needs: Document number,
Day of birth (dd/mm/yyyy)"
-> "Required fields for each user must be separated by commas and
each user must be separated by semicolons."
-> "Example: 12345678Z, 01/01/1980; 87654321Y, 01/02/1990"
* With remote census with :date_of_birth and :postal_code required:
-> "To verify a user, your application needs: Document number,
Day of birth (dd/mm/yyyy) and Postal Code"
-> "Required fields for each user must be separated by commas and
each user must be separated by semicolons."
-> "Example: 12345678Z, 01/01/1980, 28001; 87654321Y, 01/02/1990, 28002"
- In the previous version, each signature was equivalent to a document
and we separated them by commas.
Now each signature may also need the fields birth date and postal code.
So we separated each signature with a semicolon and separated each of
its fields by commas.
Example old version: "12345678X, 87654321Y"
Example new version:
"12345678X, 31/12/1980, 28001; 87654321Y, 31/12/1981, 28002"
- Update translations:
"Write the numbers separated by commas (,)" to
"Write the numbers separated by semicolons (;)"
When we reuse the partial '_setting_table' to render the 3 types
of remote census settings, we need customize setting_name key by
default to clarify the information to render.
- Add new param 'setting_name' to partial '_setting_table'
- Create new setting helper method to use new setting_name param
to display a more clarify setting name on table.
According to the feature setting["remote_census"]:
- Display info to enable tab when remote_census feature is disabled.
- Display all related setting to remote_census when feature is enabled
This model without database allow us to validate incoming file extension and
headers and also does the following during importation process:
* Ignore empty rows
* Classifiy rows in two groups: created_records, invalid_records
* Create admin controller and routes
* Add pagination
* Add search by document_number
* Add EN and ES translations
* Add index specs
* Add missing model specs
* Add to menu as a Settings sub-options
* Add translations for EN and ES locales
* Activate menu sub-option when user is at any LocalCensusRecords page
In order to not allow users to remove all persited
translations from any resource. A few exceptions were
added:
* Does not apply to globalizable models without
translatable attributes required
* Make a copy of main model error on current translations to be more realistic
- Create RemoteTranslations Controller to receive resources without
translations and create RemoteTranslation instances when theirs
translations are not enqueued.
- Create remote_translation_enqueued? class method on RemoteTranslation
model to check if exists same remote translations without errors
pending to translate.
