glitchier-soc/config/locales/simple_form.en.yml

323 lines
18 KiB
YAML
Raw Normal View History

---
en:
simple_form:
hints:
2023-06-14 05:38:07 +03:00
account:
display_name: Your full name or your fun name.
fields: Your homepage, pronouns, age, anything you want.
note: 'You can @mention other people or #hashtags.'
account_alias:
acct: Specify the username@domain of the account you want to move from
account_migration:
acct: Specify the username@domain of the account you want to move to
account_warning_preset:
text: You can use post syntax, such as URLs, hashtags and mentions
title: Optional. Not visible to the recipient
admin_account_action:
include_statuses: The user will see which posts have caused the moderation action or warning
send_email_notification: The user will receive an explanation of what happened with their account
text_html: Optional. You can use post syntax. You can <a href="%{path}">add warning presets</a> to save time
type_html: Choose what to do with <strong>%{acct}</strong>
types:
disable: Prevent the user from using their account, but do not delete or hide their contents.
none: Use this to send a warning to the user, without triggering any other action.
sensitive: Force all this user's media attachments to be flagged as sensitive.
silence: Prevent the user from being able to post with public visibility, hide their posts and notifications from people not following them. Closes all reports against this account.
suspend: Prevent any interaction from or to this account and delete its contents. Revertible within 30 days. Closes all reports against this account.
warning_preset_id: Optional. You can still add custom text to end of the preset
announcement:
all_day: When checked, only the dates of the time range will be displayed
ends_at: Optional. Announcement will be automatically unpublished at this time
scheduled_at: Leave blank to publish the announcement immediately
starts_at: Optional. In case your announcement is bound to a specific time range
text: You can use post syntax. Please be mindful of the space the announcement will take up on the user's screen
appeal:
text: You can only appeal a strike once
defaults:
autofollow: People who sign up through the invite will automatically follow you
avatar: PNG, GIF or JPG. At most %{size}. Will be downscaled to %{dimensions}px
bot: Signal to others that the account mainly performs automated actions and might not be monitored
context: One or multiple contexts where the filter should apply
current_password: For security purposes please enter the password of the current account
current_username: To confirm, please enter the username of the current account
digest: Only sent after a long period of inactivity and only if you have received any personal messages in your absence
discoverable: Allow your account to be discovered by strangers through recommendations, trends and other features
email: You will be sent a confirmation e-mail
header: PNG, GIF or JPG. At most %{size}. Will be downscaled to %{dimensions}px
inbox_url: Copy the URL from the frontpage of the relay you want to use
irreversible: Filtered posts will disappear irreversibly, even if filter is later removed
locale: The language of the user interface, e-mails and push notifications
locked: Manually control who can follow you by approving follow requests
password: Use at least 8 characters
phrase: Will be matched regardless of casing in text or content warning of a post
scopes: Which APIs the application will be allowed to access. If you select a top-level scope, you don't need to select individual ones.
setting_aggregate_reblogs: Do not show new boosts for posts that have been recently boosted (only affects newly-received boosts)
setting_always_send_emails: Normally e-mail notifications won't be sent when you are actively using Mastodon
setting_default_sensitive: Sensitive media is hidden by default and can be revealed with a click
setting_display_media_default: Hide media marked as sensitive
setting_display_media_hide_all: Always hide media
setting_display_media_show_all: Always show media
setting_hide_network: Who you follow and who follows you will be hidden on your profile
setting_noindex: Affects your public profile and post pages
setting_show_application: The application you use to post will be displayed in the detailed view of your posts
setting_use_blurhash: Gradients are based on the colors of the hidden visuals but obfuscate any details
setting_use_pending_items: Hide timeline updates behind a click instead of automatically scrolling the feed
username: You can use letters, numbers, and underscores
whole_word: When the keyword or phrase is alphanumeric only, it will only be applied if it matches the whole word
2019-07-30 12:10:46 +03:00
domain_allow:
domain: This domain will be able to fetch data from this server and incoming data from it will be processed and stored
email_domain_block:
domain: This can be the domain name that shows up in the e-mail address or the MX record it uses. They will be checked upon sign-up.
with_dns_records: An attempt to resolve the given domain's DNS records will be made and the results will also be blocked
featured_tag:
name: 'Here are some of the hashtags you used the most recently:'
Revamp post filtering system (#18058) * Add model for custom filter keywords * Use CustomFilterKeyword internally Does not change the API * Fix /filters/edit and /filters/new * Add migration tests * Remove whole_word column from custom_filters (covered by custom_filter_keywords) * Redesign /filters Instead of a list, present a card that displays more information and handles multiple keywords per filter. * Redesign /filters/new and /filters/edit to add and remove keywords This adds a new gem dependency: cocoon, as well as a npm dependency: cocoon-js-vanilla. Those are used to easily populate and remove form fields from the user interface when manipulating multiple keyword filters at once. * Add /api/v2/filters to edit filter with multiple keywords Entities: - `Filter`: `id`, `title`, `filter_action` (either `hide` or `warn`), `context` `keywords` - `FilterKeyword`: `id`, `keyword`, `whole_word` API endpoits: - `GET /api/v2/filters` to list filters (including keywords) - `POST /api/v2/filters` to create a new filter `keywords_attributes` can also be passed to create keywords in one request - `GET /api/v2/filters/:id` to read a particular filter - `PUT /api/v2/filters/:id` to update a new filter `keywords_attributes` can also be passed to edit, delete or add keywords in one request - `DELETE /api/v2/filters/:id` to delete a particular filter - `GET /api/v2/filters/:id/keywords` to list keywords for a filter - `POST /api/v2/filters/:filter_id/keywords/:id` to add a new keyword to a filter - `GET /api/v2/filter_keywords/:id` to read a particular keyword - `PUT /api/v2/filter_keywords/:id` to edit a particular keyword - `DELETE /api/v2/filter_keywords/:id` to delete a particular keyword * Change from `irreversible` boolean to `action` enum * Remove irrelevent `irreversible_must_be_within_context` check * Fix /filters/new and /filters/edit with update for filter_action * Fix Rubocop/Codeclimate complaining about task names * Refactor FeedManager#phrase_filtered? This moves regexp building and filter caching to the `CustomFilter` class. This does not change the functional behavior yet, but this changes how the cache is built, doing per-custom_filter regexps so that filters can be matched independently, while still offering caching. * Perform server-side filtering and output result in REST API * Fix numerous filters_changed events being sent when editing multiple keywords at once * Add some tests * Use the new API in the WebUI - use client-side logic for filters we have fetched rules for. This is so that filter changes can be retroactively applied without reloading the UI. - use server-side logic for filters we haven't fetched rules for yet (e.g. network error, or initial timeline loading) * Minor optimizations and refactoring * Perform server-side filtering on the streaming server * Change the wording of filter action labels * Fix issues pointed out by linter * Change design of “Show anyway” link in accordence to review comments * Drop “irreversible” filtering behavior * Move /api/v2/filter_keywords to /api/v1/filters/keywords * Rename `filter_results` attribute to `filtered` * Rename REST::LegacyFilterSerializer to REST::V1::FilterSerializer * Fix systemChannelId value in streaming server * Simplify code by removing client-side filtering code The simplifcation comes at a cost though: filters aren't retroactively applied anymore.
2022-06-28 10:42:13 +03:00
filters:
action: Chose which action to perform when a post matches the filter
actions:
hide: Completely hide the filtered content, behaving as if it did not exist
warn: Hide the filtered content behind a warning mentioning the filter's title
form_admin_settings:
activity_api_enabled: Counts of locally published posts, active users, and new registrations in weekly buckets
backups_retention_period: Keep generated user archives for the specified number of days.
bootstrap_timeline_accounts: These accounts will be pinned to the top of new users' follow recommendations.
closed_registrations_message: Displayed when sign-ups are closed
content_cache_retention_period: All posts and boosts from other servers will be deleted after the specified number of days. Some posts may not be recoverable. All related bookmarks, favourites and boosts will also be lost and impossible to undo.
custom_css: You can apply custom styles on the web version of Mastodon.
mascot: Overrides the illustration in the advanced web interface.
media_cache_retention_period: Downloaded media files will be deleted after the specified number of days when set to a positive value, and re-downloaded on demand.
peers_api_enabled: A list of domain names this server has encountered in the fediverse. No data is included here about whether you federate with a given server, just that your server knows about it. This is used by services that collect statistics on federation in a general sense.
profile_directory: The profile directory lists all users who have opted-in to be discoverable.
require_invite_text: When sign-ups require manual approval, make the “Why do you want to join?” text input mandatory rather than optional
site_contact_email: How people can reach you for legal or support inquiries.
site_contact_username: How people can reach you on Mastodon.
site_extended_description: Any additional information that may be useful to visitors and your users. Can be structured with Markdown syntax.
site_short_description: A short description to help uniquely identify your server. Who is running it, who is it for?
site_terms: Use your own privacy policy or leave blank to use the default. Can be structured with Markdown syntax.
site_title: How people may refer to your server besides its domain name.
status_page_url: URL of a page where people can see the status of this server during an outage
theme: Theme that logged out visitors and new users see.
thumbnail: A roughly 2:1 image displayed alongside your server information.
timeline_preview: Logged out visitors will be able to browse the most recent public posts available on the server.
trendable_by_default: Skip manual review of trending content. Individual items can still be removed from trends after the fact.
trends: Trends show which posts, hashtags and news stories are gaining traction on your server.
trends_as_landing_page: Show trending content to logged-out users and visitors instead of a description of this server. Requires trends to be enabled.
form_challenge:
current_password: You are entering a secure area
imports:
data: CSV file exported from another Mastodon server
invite_request:
text: This will help us review your application
2020-10-12 17:33:49 +03:00
ip_block:
comment: Optional. Remember why you added this rule.
expires_in: IP addresses are a finite resource, they are sometimes shared and often change hands. For this reason, indefinite IP blocks are not recommended.
ip: Enter an IPv4 or IPv6 address. You can block entire ranges using the CIDR syntax. Be careful not to lock yourself out!
severities:
no_access: Block access to all resources
sign_up_block: New sign-ups will not be possible
2020-10-12 17:33:49 +03:00
sign_up_requires_approval: New sign-ups will require your approval
severity: Choose what will happen with requests from this IP
2021-02-21 20:50:12 +02:00
rule:
text: Describe a rule or requirement for users on this server. Try to keep it short and simple
sessions:
otp: 'Enter the two-factor code generated by your phone app or use one of your recovery codes:'
Add WebAuthn as an alternative 2FA method (#14466) * feat: add possibility of adding WebAuthn security keys to use as 2FA This adds a basic UI for enabling WebAuthn 2FA. We did a little refactor to the Settings page for editing the 2FA methods – now it will list the methods that are available to the user (TOTP and WebAuthn) and from there they'll be able to add or remove any of them. Also, it's worth mentioning that for enabling WebAuthn it's required to have TOTP enabled, so the first time that you go to the 2FA Settings page, you'll be asked to set it up. This work was inspired by the one donde by Github in their platform, and despite it could be approached in different ways, we decided to go with this one given that we feel that this gives a great UX. Co-authored-by: Facundo Padula <facundo.padula@cedarcode.com> * feat: add request for WebAuthn as second factor at login if enabled This commits adds the feature for using WebAuthn as a second factor for login when enabled. If users have WebAuthn enabled, now a page requesting for the use of a WebAuthn credential for log in will appear, although a link redirecting to the old page for logging in using a two-factor code will also be present. Co-authored-by: Facundo Padula <facundo.padula@cedarcode.com> * feat: add possibility of deleting WebAuthn Credentials Co-authored-by: Facundo Padula <facundo.padula@cedarcode.com> * feat: disable WebAuthn when an Admin disables 2FA for a user Co-authored-by: Facundo Padula <facundo.padula@cedarcode.com> * feat: remove ability to disable TOTP leaving only WebAuthn as 2FA Following examples form other platforms like Github, we decided to make Webauthn 2FA secondary to 2FA with TOTP, so that we removed the possibility of removing TOTP authentication only, leaving users with just WEbAuthn as 2FA. Instead, users will have to click on 'Disable 2FA' in order to remove second factor auth. The reason for WebAuthn being secondary to TOPT is that in that way, users will still be able to log in using their code from their phone's application if they don't have their security keys with them – or maybe even lost them. * We had to change a little the flow for setting up TOTP, given that now it's possible to setting up again if you already had TOTP, in order to let users modify their authenticator app – given that now it's not possible for them to disable TOTP and set it up again with another authenticator app. So, basically, now instead of storing the new `otp_secret` in the user, we store it in the session until the process of set up is finished. This was because, as it was before, when users clicked on 'Edit' in the new two-factor methods lists page, but then went back without finishing the flow, their `otp_secret` had been changed therefore invalidating their previous authenticator app, making them unable to log in again using TOTP. Co-authored-by: Facundo Padula <facundo.padula@cedarcode.com> * refactor: fix eslint errors The PR build was failing given that linting returning some errors. This commit attempts to fix them. * refactor: normalize i18n translations The build was failing given that i18n translations files were not normalized. This commits fixes that. * refactor: avoid having the webauthn gem locked to a specific version * refactor: use symbols for routes without '/' * refactor: avoid sending webauthn disabled email when 2FA is disabled When an admins disable 2FA for users, we were sending two mails to them, one notifying that 2FA was disabled and the other to notify that WebAuthn was disabled. As the second one is redundant since the first email includes it, we can remove it and send just one email to users. * refactor: avoid creating new env variable for webauthn_origin config * refactor: improve flash error messages for webauthn pages Co-authored-by: Facundo Padula <facundo.padula@cedarcode.com>
2020-08-24 17:46:27 +03:00
webauthn: If it's an USB key be sure to insert it and, if necessary, tap it.
tag:
name: You can only change the casing of the letters, for example, to make it more readable
user:
chosen_languages: When checked, only posts in selected languages will be displayed in public timelines
role: The role controls which permissions the user has
user_role:
color: Color to be used for the role throughout the UI, as RGB in hex format
highlighted: This makes the role publicly visible
name: Public name of the role, if role is set to be displayed as a badge
permissions_as_keys: Users with this role will have access to...
position: Higher role decides conflict resolution in certain situations. Certain actions can only be performed on roles with a lower priority
webhook:
events: Select events to send
template: Compose your own JSON payload using variable interpolation. Leave blank for default JSON.
url: Where events will be sent to
2016-11-16 00:02:57 +02:00
labels:
account:
fields:
name: Label
value: Content
account_alias:
acct: Handle of the old account
account_migration:
acct: Handle of the new account
account_warning_preset:
text: Preset text
title: Title
admin_account_action:
include_statuses: Include reported posts in the e-mail
send_email_notification: Notify the user per e-mail
text: Custom warning
type: Action
types:
disable: Freeze
none: Send a warning
sensitive: Sensitive
silence: Limit
suspend: Suspend
warning_preset_id: Use a warning preset
announcement:
all_day: All-day event
ends_at: End of event
scheduled_at: Schedule publication
2020-01-29 19:39:44 +02:00
starts_at: Start of event
text: Announcement
appeal:
text: Explain why this decision should be reversed
2016-11-16 00:02:57 +02:00
defaults:
autofollow: Invite to follow your account
2023-06-14 05:38:07 +03:00
avatar: Profile picture
bot: This is an automated account
chosen_languages: Filter languages
2016-11-16 00:02:57 +02:00
confirm_new_password: Confirm new password
confirm_password: Confirm password
context: Filter contexts
2016-11-16 00:02:57 +02:00
current_password: Current password
data: Data
discoverable: Suggest account to others
2016-11-16 00:02:57 +02:00
display_name: Display name
email: E-mail address
expires_in: Expire after
2023-06-14 05:38:07 +03:00
fields: Extra fields
header: Header picture
honeypot: "%{label} (do not fill in)"
inbox_url: URL of the relay inbox
irreversible: Drop instead of hide
locale: Interface language
locked: Require follow requests
max_uses: Max number of uses
new_password: New password
note: Bio
2017-01-28 21:43:38 +02:00
otp_attempt: Two-factor code
password: Password
phrase: Keyword or phrase
setting_advanced_layout: Enable advanced web interface
setting_aggregate_reblogs: Group boosts in timelines
setting_always_send_emails: Always send e-mail notifications
setting_auto_play_gif: Auto-play animated GIFs
setting_boost_modal: Show confirmation dialog before boosting
setting_default_language: Posting language
setting_default_privacy: Posting privacy
setting_default_sensitive: Always mark media as sensitive
setting_delete_modal: Show confirmation dialog before deleting a post
setting_disable_swiping: Disable swiping motions
setting_display_media: Media display
setting_display_media_default: Default
setting_display_media_hide_all: Hide all
setting_display_media_show_all: Show all
setting_expand_spoilers: Always expand posts marked with content warnings
setting_hide_network: Hide your social graph
setting_noindex: Opt-out of search engine indexing
setting_reduce_motion: Reduce motion in animations
setting_show_application: Disclose application used to send posts
setting_system_font_ui: Use system's default font
2017-10-01 11:52:39 +03:00
setting_theme: Site theme
setting_trends: Show today's trends
setting_unfollow_modal: Show confirmation dialog before unfollowing someone
setting_use_blurhash: Show colorful gradients for hidden media
setting_use_pending_items: Slow mode
severity: Severity
sign_in_token_attempt: Security code
Revamp post filtering system (#18058) * Add model for custom filter keywords * Use CustomFilterKeyword internally Does not change the API * Fix /filters/edit and /filters/new * Add migration tests * Remove whole_word column from custom_filters (covered by custom_filter_keywords) * Redesign /filters Instead of a list, present a card that displays more information and handles multiple keywords per filter. * Redesign /filters/new and /filters/edit to add and remove keywords This adds a new gem dependency: cocoon, as well as a npm dependency: cocoon-js-vanilla. Those are used to easily populate and remove form fields from the user interface when manipulating multiple keyword filters at once. * Add /api/v2/filters to edit filter with multiple keywords Entities: - `Filter`: `id`, `title`, `filter_action` (either `hide` or `warn`), `context` `keywords` - `FilterKeyword`: `id`, `keyword`, `whole_word` API endpoits: - `GET /api/v2/filters` to list filters (including keywords) - `POST /api/v2/filters` to create a new filter `keywords_attributes` can also be passed to create keywords in one request - `GET /api/v2/filters/:id` to read a particular filter - `PUT /api/v2/filters/:id` to update a new filter `keywords_attributes` can also be passed to edit, delete or add keywords in one request - `DELETE /api/v2/filters/:id` to delete a particular filter - `GET /api/v2/filters/:id/keywords` to list keywords for a filter - `POST /api/v2/filters/:filter_id/keywords/:id` to add a new keyword to a filter - `GET /api/v2/filter_keywords/:id` to read a particular keyword - `PUT /api/v2/filter_keywords/:id` to edit a particular keyword - `DELETE /api/v2/filter_keywords/:id` to delete a particular keyword * Change from `irreversible` boolean to `action` enum * Remove irrelevent `irreversible_must_be_within_context` check * Fix /filters/new and /filters/edit with update for filter_action * Fix Rubocop/Codeclimate complaining about task names * Refactor FeedManager#phrase_filtered? This moves regexp building and filter caching to the `CustomFilter` class. This does not change the functional behavior yet, but this changes how the cache is built, doing per-custom_filter regexps so that filters can be matched independently, while still offering caching. * Perform server-side filtering and output result in REST API * Fix numerous filters_changed events being sent when editing multiple keywords at once * Add some tests * Use the new API in the WebUI - use client-side logic for filters we have fetched rules for. This is so that filter changes can be retroactively applied without reloading the UI. - use server-side logic for filters we haven't fetched rules for yet (e.g. network error, or initial timeline loading) * Minor optimizations and refactoring * Perform server-side filtering on the streaming server * Change the wording of filter action labels * Fix issues pointed out by linter * Change design of “Show anyway” link in accordence to review comments * Drop “irreversible” filtering behavior * Move /api/v2/filter_keywords to /api/v1/filters/keywords * Rename `filter_results` attribute to `filtered` * Rename REST::LegacyFilterSerializer to REST::V1::FilterSerializer * Fix systemChannelId value in streaming server * Simplify code by removing client-side filtering code The simplifcation comes at a cost though: filters aren't retroactively applied anymore.
2022-06-28 10:42:13 +03:00
title: Title
type: Import type
2016-11-22 12:34:36 +02:00
username: Username
username_or_email: Username or Email
whole_word: Whole word
email_domain_block:
with_dns_records: Include MX records and IPs of the domain
featured_tag:
name: Hashtag
Revamp post filtering system (#18058) * Add model for custom filter keywords * Use CustomFilterKeyword internally Does not change the API * Fix /filters/edit and /filters/new * Add migration tests * Remove whole_word column from custom_filters (covered by custom_filter_keywords) * Redesign /filters Instead of a list, present a card that displays more information and handles multiple keywords per filter. * Redesign /filters/new and /filters/edit to add and remove keywords This adds a new gem dependency: cocoon, as well as a npm dependency: cocoon-js-vanilla. Those are used to easily populate and remove form fields from the user interface when manipulating multiple keyword filters at once. * Add /api/v2/filters to edit filter with multiple keywords Entities: - `Filter`: `id`, `title`, `filter_action` (either `hide` or `warn`), `context` `keywords` - `FilterKeyword`: `id`, `keyword`, `whole_word` API endpoits: - `GET /api/v2/filters` to list filters (including keywords) - `POST /api/v2/filters` to create a new filter `keywords_attributes` can also be passed to create keywords in one request - `GET /api/v2/filters/:id` to read a particular filter - `PUT /api/v2/filters/:id` to update a new filter `keywords_attributes` can also be passed to edit, delete or add keywords in one request - `DELETE /api/v2/filters/:id` to delete a particular filter - `GET /api/v2/filters/:id/keywords` to list keywords for a filter - `POST /api/v2/filters/:filter_id/keywords/:id` to add a new keyword to a filter - `GET /api/v2/filter_keywords/:id` to read a particular keyword - `PUT /api/v2/filter_keywords/:id` to edit a particular keyword - `DELETE /api/v2/filter_keywords/:id` to delete a particular keyword * Change from `irreversible` boolean to `action` enum * Remove irrelevent `irreversible_must_be_within_context` check * Fix /filters/new and /filters/edit with update for filter_action * Fix Rubocop/Codeclimate complaining about task names * Refactor FeedManager#phrase_filtered? This moves regexp building and filter caching to the `CustomFilter` class. This does not change the functional behavior yet, but this changes how the cache is built, doing per-custom_filter regexps so that filters can be matched independently, while still offering caching. * Perform server-side filtering and output result in REST API * Fix numerous filters_changed events being sent when editing multiple keywords at once * Add some tests * Use the new API in the WebUI - use client-side logic for filters we have fetched rules for. This is so that filter changes can be retroactively applied without reloading the UI. - use server-side logic for filters we haven't fetched rules for yet (e.g. network error, or initial timeline loading) * Minor optimizations and refactoring * Perform server-side filtering on the streaming server * Change the wording of filter action labels * Fix issues pointed out by linter * Change design of “Show anyway” link in accordence to review comments * Drop “irreversible” filtering behavior * Move /api/v2/filter_keywords to /api/v1/filters/keywords * Rename `filter_results` attribute to `filtered` * Rename REST::LegacyFilterSerializer to REST::V1::FilterSerializer * Fix systemChannelId value in streaming server * Simplify code by removing client-side filtering code The simplifcation comes at a cost though: filters aren't retroactively applied anymore.
2022-06-28 10:42:13 +03:00
filters:
actions:
hide: Hide completely
warn: Hide with a warning
form_admin_settings:
activity_api_enabled: Publish aggregate statistics about user activity in the API
backups_retention_period: User archive retention period
bootstrap_timeline_accounts: Always recommend these accounts to new users
closed_registrations_message: Custom message when sign-ups are not available
content_cache_retention_period: Content cache retention period
custom_css: Custom CSS
mascot: Custom mascot (legacy)
media_cache_retention_period: Media cache retention period
peers_api_enabled: Publish list of discovered servers in the API
profile_directory: Enable profile directory
registrations_mode: Who can sign-up
require_invite_text: Require a reason to join
show_domain_blocks: Show domain blocks
show_domain_blocks_rationale: Show why domains were blocked
site_contact_email: Contact e-mail
site_contact_username: Contact username
site_extended_description: Extended description
site_short_description: Server description
site_terms: Privacy Policy
site_title: Server name
status_page_url: Status page URL
theme: Default theme
thumbnail: Server thumbnail
timeline_preview: Allow unauthenticated access to public timelines
trendable_by_default: Allow trends without prior review
trends: Enable trends
trends_as_landing_page: Use trends as the landing page
2016-11-25 14:15:07 +02:00
interactions:
must_be_follower: Block notifications from non-followers
must_be_following: Block notifications from people you don't follow
must_be_following_dm: Block direct messages from people you don't follow
invite:
comment: Comment
invite_request:
text: Why do you want to join?
2020-10-12 17:33:49 +03:00
ip_block:
comment: Comment
ip: IP
severities:
no_access: Block access
sign_up_block: Block sign-ups
2020-10-12 17:33:49 +03:00
sign_up_requires_approval: Limit sign-ups
severity: Rule
2016-11-16 00:02:57 +02:00
notification_emails:
appeal: Someone appeals a moderator decision
2017-03-19 21:29:41 +02:00
digest: Send digest e-mails
favourite: Someone favourited your post
follow: Someone followed you
follow_request: Someone requested to follow you
mention: Someone mentioned you
pending_account: New account needs review
reblog: Someone boosted your post
report: New report is submitted
trending_tag: New trend requires review
2021-02-21 20:50:12 +02:00
rule:
text: Rule
tag:
listable: Allow this hashtag to appear in searches and suggestions
name: Hashtag
trendable: Allow this hashtag to appear under trends
usable: Allow posts to use this hashtag
user:
role: Role
2023-06-10 04:29:37 +03:00
time_zone: Time zone
user_role:
color: Badge color
highlighted: Display role as badge on user profiles
name: Name
permissions_as_keys: Permissions
position: Priority
webhook:
events: Enabled events
template: Payload template
url: Endpoint URL
'no': 'No'
not_recommended: Not recommended
recommended: Recommended
required:
mark: "*"
text: required
Add WebAuthn as an alternative 2FA method (#14466) * feat: add possibility of adding WebAuthn security keys to use as 2FA This adds a basic UI for enabling WebAuthn 2FA. We did a little refactor to the Settings page for editing the 2FA methods – now it will list the methods that are available to the user (TOTP and WebAuthn) and from there they'll be able to add or remove any of them. Also, it's worth mentioning that for enabling WebAuthn it's required to have TOTP enabled, so the first time that you go to the 2FA Settings page, you'll be asked to set it up. This work was inspired by the one donde by Github in their platform, and despite it could be approached in different ways, we decided to go with this one given that we feel that this gives a great UX. Co-authored-by: Facundo Padula <facundo.padula@cedarcode.com> * feat: add request for WebAuthn as second factor at login if enabled This commits adds the feature for using WebAuthn as a second factor for login when enabled. If users have WebAuthn enabled, now a page requesting for the use of a WebAuthn credential for log in will appear, although a link redirecting to the old page for logging in using a two-factor code will also be present. Co-authored-by: Facundo Padula <facundo.padula@cedarcode.com> * feat: add possibility of deleting WebAuthn Credentials Co-authored-by: Facundo Padula <facundo.padula@cedarcode.com> * feat: disable WebAuthn when an Admin disables 2FA for a user Co-authored-by: Facundo Padula <facundo.padula@cedarcode.com> * feat: remove ability to disable TOTP leaving only WebAuthn as 2FA Following examples form other platforms like Github, we decided to make Webauthn 2FA secondary to 2FA with TOTP, so that we removed the possibility of removing TOTP authentication only, leaving users with just WEbAuthn as 2FA. Instead, users will have to click on 'Disable 2FA' in order to remove second factor auth. The reason for WebAuthn being secondary to TOPT is that in that way, users will still be able to log in using their code from their phone's application if they don't have their security keys with them – or maybe even lost them. * We had to change a little the flow for setting up TOTP, given that now it's possible to setting up again if you already had TOTP, in order to let users modify their authenticator app – given that now it's not possible for them to disable TOTP and set it up again with another authenticator app. So, basically, now instead of storing the new `otp_secret` in the user, we store it in the session until the process of set up is finished. This was because, as it was before, when users clicked on 'Edit' in the new two-factor methods lists page, but then went back without finishing the flow, their `otp_secret` had been changed therefore invalidating their previous authenticator app, making them unable to log in again using TOTP. Co-authored-by: Facundo Padula <facundo.padula@cedarcode.com> * refactor: fix eslint errors The PR build was failing given that linting returning some errors. This commit attempts to fix them. * refactor: normalize i18n translations The build was failing given that i18n translations files were not normalized. This commits fixes that. * refactor: avoid having the webauthn gem locked to a specific version * refactor: use symbols for routes without '/' * refactor: avoid sending webauthn disabled email when 2FA is disabled When an admins disable 2FA for users, we were sending two mails to them, one notifying that 2FA was disabled and the other to notify that WebAuthn was disabled. As the second one is redundant since the first email includes it, we can remove it and send just one email to users. * refactor: avoid creating new env variable for webauthn_origin config * refactor: improve flash error messages for webauthn pages Co-authored-by: Facundo Padula <facundo.padula@cedarcode.com>
2020-08-24 17:46:27 +03:00
title:
sessions:
webauthn: Use one of your security keys to sign in
'yes': 'Yes'