Refactor Time-related Fields ahead of upcoming improvements#2702
Closed
goosys wants to merge 2 commits intothoughtbot:mainfrom
Closed
Refactor Time-related Fields ahead of upcoming improvements#2702goosys wants to merge 2 commits intothoughtbot:mainfrom
goosys wants to merge 2 commits intothoughtbot:mainfrom
Conversation
Member
|
Thanks! These changes all look sensible to me. Could you break them out into individual commits (and so PRs)?
Where would |
This was referenced Feb 18, 2025
Contributor
Author
I've done that. Could you review them again?
We can enable this by configuring it in i18n. There are two possible approaches:
If we choose to define all of them separately, it would look like the following (though I haven't tested it yet). module Administrate
module Field
class DateTime < Base
def date
I18n.localize(
data.in_time_zone(timezone).to_date,
format: format_date
)
end
def datetime
I18n.localize(
data.in_time_zone(timezone),
format: format_datetime
)
end
private
def format_date
options.fetch(:format, :administrate_date_default)
end
def format_datetime
options.fetch(:format, :administrate_datetime_default)
end |
Contributor
Author
|
Thank you. I have created a new PR for the next task, so I will close this one. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
I initially planned to improve the i18n for Time-related fields, but I realized some preliminary refactoring was necessary. I’ve made a few small adjustments and would appreciate your review.
Field::Time#timeto always go throughI18n.localize:formatoption wasn’t specified, it bypassedtranslate_localization_format, so AM/PM was not localized.defaultoption fromI18n.localize:data.in_time_zonewhendataisnil, thedefaultoption was not meaningful..name:in_time_zonecan acceptTime.zoneobjects directly, so string conversion is also unnecessary.Customer.example_timeto the Dashboard in the example app to check the behavior of theField::Time.rails-i18ngem, we don’t have to worry about am/pm translations being undefined.Next, I’d like to make the following adjustments. What do you think?
options.fetch(:format, :administrate_datetime_default)as the default format value:defaultformat used in the main application outside of the Administrate panel."%I:%M%p", but in Japanese, we would prefer the order"%p %I:%M". I believe other languages may also have their own preferred orders.formatoption to be passed into public methods.field.time(format: :administrate_time_short), while in the show view, simply callingfield.timewould apply:administrate_time_default.