-
Notifications
You must be signed in to change notification settings - Fork 4.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix font library modal dialog translatable strings #58256
Conversation
Size Change: -45 B (0%) Total Size: 1.7 MB
ℹ️ View Unchanged
|
packages/editor/src/utils/l10n.js
Outdated
*/ | ||
import { __ } from '@wordpress/i18n'; | ||
|
||
export const l10n = { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you share more about this? Why is this in the editor package? Can we instead just use the string where we need it?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm guessing the goal is to have a central place for these localized things.
I feel like "editor" is not the right package for that. Maybe a dedicated package like @wordpress/locale
or something.
Also, since it's only used in one place now, maybe it's fine to start adhoc.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this is probably aiming to implement a function equivalent to WP Core's wp_get_list_item_separator()
function, as mentioned in this comment. Personally, I think adhoc is fine for now.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you share more about this? Why is this in the editor package? Can we instead just use the string where we need it?
@youknowriad I tried to explain that in the PR summary:
Introduces a l10n object in the editor/utils package. For now, it only contains a listItemSeparator string. In the future this could be expanded with more strings, reshaped, or even moved to a separate package if desired. Pleaae let me know if the current approach is acceptable
I don't think we should fix it on a 'per case' basis as there are other occurrences. I created #58265
Glad to move to a new package if desired. I think in the future there would be the need for more l10n things but for now it's just this tiny string...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For this particular case, I think it will make the code simpler if we use just the string .tff, .otf, .woff, .woff2
. The loop to iterate over the file extensions is not necessary and it seems like an overkill because that info is unlikely to changes for a good amount of time.
sprintf( | ||
/* translators: %d: Number of font variants. */ | ||
_n( | ||
'%d variant', | ||
'%d variants', | ||
variantsCount | ||
), | ||
variantsCount | ||
) } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice addition, thanks.
packages/editor/src/utils/l10n.js
Outdated
*/ | ||
import { __ } from '@wordpress/i18n'; | ||
|
||
export const l10n = { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For this particular case, I think it will make the code simpler if we use just the string .tff, .otf, .woff, .woff2
. The loop to iterate over the file extensions is not necessary and it seems like an overkill because that info is unlikely to changes for a good amount of time.
const { listItemSeparator } = l10n; | ||
|
||
const supportedFormats = ALLOWED_FILE_EXTENSIONS.map( | ||
( extension ) => `.${ extension }` | ||
).join( listItemSeparator ); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This seems like an overkill because this info is unlikely to change.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Glad to simplify all of that and just provide a string, agree it's a bit overkill.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The translation strings are looking better. Thanks for this improvement. LGTM
Thanks for the review. |
954e571
to
496fcd5
Compare
Rebased after changes from #58180 |
Fixes #58201
What?
A couple translatable strings are not translatable as they don't follow the WordPress localization best practices and are unnecessarily comples.
Why?
Following the WordPress localization best practices makes sure strings are translatable to all languages. For example:
sprintg
and placeholder appropriately.,
must be translatable as well.How?
sprintf
where appropriate.Removes a__( 'and' )
translatable string anc concatenation.Introduces al10n
object in theeditor/utils
package. For now, it only contains alistItemSeparator
string. In the future this could be expanded with more strings, reshaped, or even moved to a separate package if desired. Pleaae let me know if the current approach is acceptable Cc @youknowriad @SergeyBiryukovNote: in Core, the list item separator comes from
WP_Locale->get_list_item_separator()
. It is in a centralized location and can be reused across the codebase. I'd think something similar is worth introducing also in Gutenberg.Testing Instructions
Testing Instructions for Keyboard
Screenshots or screencast