Skip to content
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

Add i18n context for resolving invalid blocks #10779

Merged
merged 2 commits into from Oct 27, 2018

Conversation

@brandonpayton
Copy link
Member

commented Oct 19, 2018

Description

This is a simple PR to add i18n context for "Resolve" and "Resolve Block" strings to resolve translation concerns from this comment.

@gAllegr, does this address your issue with the strings?

Screenshots

screen shot 2018-10-19 at 12 18 12 am

screen shot 2018-10-19 at 12 18 20 am

@gAllegr

This comment has been minimized.

Copy link

commented Oct 19, 2018

Yes, thank you, these screenshots are much more explicative.
Even better would be add a specific comment for the two strings, something like the following screenshot. While translating it's not obvious where strings are located.
Maybe Button to fix content for Resolve string and Window title to fix content for the Resolve block one?

comment

@brandonpayton brandonpayton force-pushed the add/context-for-block-resolve-strings branch from 06bab87 to 4593fb8 Oct 25, 2018
@brandonpayton

This comment has been minimized.

Copy link
Member Author

commented Oct 25, 2018

Thanks for the additional suggestions, @gAllegr. This is good to be learning.

I made an update based on your comments. How does the latest look?

@mcsf
mcsf approved these changes Oct 26, 2018
Copy link
Contributor

left a comment

Nitpick: is the line break needed at all?

// translators: Dialog title to fix block content
title={ __( 'Resolve Block' ) }

other than that question: good to merge, the notes and syntactic case are good.

@aduth

This comment has been minimized.

Copy link
Member

commented Oct 26, 2018

Nitpick: is the line break needed at all?

The parser is a little picky, and while the comment doesn't need to strictly be a leading comment of the translation call, it does need to be a leading comment of one of its parents in the AST hierarchy. This might actually work here as the leading comment of the attribute assignment, but it's worth verifying.

tl;dr The parser doesn't strictly consider "previous line", it considers leading comments of its AST ancestry which occur on the current or previous line.

See

/**
* Returns translator comment for a given AST traversal path if one exists.
*
* @param {Object} path Traversal path.
* @param {number} _originalNodeLine Private: In recursion, line number of
* the original node passed.
*
* @return {?string} Translator comment.
*/
function getTranslatorComment( path, _originalNodeLine ) {
const { node, parent, parentPath } = path;
// Assign original node line so we can keep track in recursion whether a
// matched comment or parent occurs on the same or previous line
if ( ! _originalNodeLine ) {
_originalNodeLine = node.loc.start.line;
}
let comment;
forEach( node.leadingComments, ( commentNode ) => {
const { line } = commentNode.loc.end;
if ( line < _originalNodeLine - 1 || line > _originalNodeLine ) {
return;
}
const match = commentNode.value.match( REGEXP_TRANSLATOR_COMMENT );
if ( match ) {
// Extract text from matched translator prefix
comment = match[ 1 ].split( '\n' ).map( ( text ) => text.trim() ).join( ' ' );
// False return indicates to Lodash to break iteration
return false;
}
} );
if ( comment ) {
return comment;
}
if ( ! parent || ! parent.loc || ! parentPath ) {
return;
}
// Only recurse as long as parent node is on the same or previous line
const { line } = parent.loc.start;
if ( line >= _originalNodeLine - 1 && line <= _originalNodeLine ) {
return getTranslatorComment( parentPath, _originalNodeLine );
}
}

@gAllegr

This comment has been minimized.

Copy link

commented Oct 26, 2018

Thanks for the additional suggestions, @gAllegr. This is good to be learning.

I made an update based on your comments. How does the latest look?

Looks ok to me
Generally speaking, while coding and preparing for internationalization, if you found something that might generate confusion it is great to add a comment for translators

@youknowriad youknowriad merged commit 9d33098 into master Oct 27, 2018
2 checks passed
2 checks passed
codecov/project 48.89% remains the same compared to fb9fa03
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details
@youknowriad youknowriad deleted the add/context-for-block-resolve-strings branch Oct 27, 2018
@aduth

This comment has been minimized.

Copy link
Member

commented Nov 6, 2018

Nitpick: is the line break needed at all?

Based on #11494 / #11514, it appears it is needed (as merged here should be fine).

grey-rsi pushed a commit to OnTheGoSystems/gutenberg that referenced this pull request Nov 22, 2018
* Add i18n context for resolving invalid blocks

* Add translators comments based on feedback
grey-rsi pushed a commit to OnTheGoSystems/gutenberg that referenced this pull request Jan 4, 2019
* Add i18n context for resolving invalid blocks

* Add translators comments based on feedback
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
7 participants
You can’t perform that action at this time.