-
Notifications
You must be signed in to change notification settings - Fork 16
Added new param state to translation parses #615
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
base: master
Are you sure you want to change the base?
Conversation
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.
Pull Request Overview
This PR adds support for a new state
parameter in translation parsing that can indicate whether content is 'original' or 'translated'. The change extends the existing translation system to handle a third type of directive alongside context and from parameters.
- Added
state
field toTranslatableMessageV2
interface with union type'original' | 'translated'
- Introduced
STATE_REGEX
pattern[[[state]]]
and updatedCONTENT_REGEX
to include it - Added early return logic to skip translation processing when state is 'translated'
Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.
content: content?.trim(), | ||
context: context?.trim(), | ||
from: from?.trim(), | ||
state: state?.trim() as 'original' | 'translated' | undefined, |
Copilot
AI
Oct 9, 2025
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 type assertion bypasses TypeScript's type checking. The state?.trim()
result could be any string, but you're asserting it's one of the expected literal types. Consider adding runtime validation to ensure the state value is actually 'original' or 'translated' before the type assertion.
state: state?.trim() as 'original' | 'translated' | undefined, | |
state: (state?.trim() === 'original' || state?.trim() === 'translated') | |
? (state?.trim() as 'original' | 'translated') | |
: undefined, |
Copilot uses AI. Check for mistakes.
content: content?.trim(), | ||
context: context?.trim(), | ||
from: from?.trim(), | ||
state: state?.trim() as 'original' | 'translated' | undefined, |
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.
state: (state?.trim() == 'translated' ? 'translated' : 'original') as 'translated' | 'original'
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.
Pull Request Overview
Copilot reviewed 1 out of 1 changed files in this pull request and generated 2 comments.
Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.
content: content?.trim(), | ||
context: context?.trim(), | ||
from: from?.trim(), | ||
state: (state?.trim() === 'translated' ? 'translated' : 'original') as 'translated' | 'original', |
Copilot
AI
Oct 13, 2025
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 type assertion is redundant since the ternary operator already ensures the return type matches the union type. Consider simplifying to: state: state?.trim() === 'translated' ? 'translated' : 'original'
state: (state?.trim() === 'translated' ? 'translated' : 'original') as 'translated' | 'original', | |
state: state?.trim() === 'translated' ? 'translated' : 'original', |
Copilot uses AI. Check for mistakes.
export const formatTranslatableStringV2 = ({ from, content, context }: TranslatableMessageV2): string => | ||
`${content} ${context ? `(((${context})))` : ''} ${from ? `<<<${from}>>>` : ''}` | ||
export const formatTranslatableStringV2 = ({ from, content, context, state }: TranslatableMessageV2): string => | ||
`${content} ${context ? `(((${context})))` : ''} ${from ? `<<<${from}>>>` : ''} ${state ? `[[[${state}]]]` : ''}` |
Copilot
AI
Oct 13, 2025
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 formatting function includes the state marker even when state is 'original', which may add unnecessary markers to strings. Consider only including the state marker when it's 'translated' to keep the output cleaner for the default case.
`${content} ${context ? `(((${context})))` : ''} ${from ? `<<<${from}>>>` : ''} ${state ? `[[[${state}]]]` : ''}` | |
`${content} ${context ? `(((${context})))` : ''} ${from ? `<<<${from}>>>` : ''} ${state === 'translated' ? `[[[${state}]]]` : ''}` |
Copilot uses AI. Check for mistakes.
What is the purpose of this pull request?
This pull request enhances the translation utilities in
src/service/worker/runtime/graphql/utils/translations.ts
by introducing a newstate
marker for translatable message strings, updating the parsing and formatting logic to handle this marker, and ensuring that already translated messages are bypassed further processing. These changes make the translation pipeline more robust and prevent unnecessary re-translation.Support for message state and translation control:
[[[state]]]
marker in translatable strings, updating theCONTENT_REGEX
and introducingSTATE_REGEX
to match and extract the state (either'original'
or'translated'
). TheTranslatableMessageV2
interface and related parsing/formatting functions were updated to handle this new field.parseTranslatableStringV2
to extract thestate
from the message and default to'original'
if not specified.formatTranslatableStringV2
to include the[[[state]]]
marker when formatting messages, ensuring the state is preserved in the string representation.handleSingleString
, added logic to immediately return the message content if itsstate
is'translated'
, preventing already translated messages from being processed again.What problem is this solving?
How it works today:
The catalog returns the request data. A @translatableV2 notation causes some GraphQL keys to be intercepted and translated.
Where we want to go:
The catalog returns the data that needs to be translated already translated. The @translatableV2 flag is removed, centralizing the translation process in the catalog dataplane indexing.
How we'll do the from-to:
Important points
This PR adds an additional parameter that marks a label as already translated, causing @vtex-node-api to intercept the label but return only the original text, even if the @translatableV2 flag is active.
How should this be manually tested?
Screenshots or example usage
Types of changes