{"section":"known-issues","requestedLocale":"en","requestedSlug":"specification-values-not-being-translated-in-intelligent-search-side","locale":"en","slug":"specification-values-not-being-translated-in-intelligent-search-side","path":"docs/en/known-issues/Intelligent Search/specification-values-not-being-translated-in-intelligent-search-side.md","branch":"main","content":"## Summary\n\nTranslating fields from one language to another using `vtex.catalog-graphql` app and making them available to be searched inside the Intelligent Search is not working properly.\n\nThe indexing process and the `vtex.catalog-graphql`_ _app differ when handling Specification Values. The difference is that when calling `vtex.messages`, the indexing process uses the Specification Value's _FieldValueId_, and when registering translations, the `vtex.catalog-graphql` uses the Specification's _FieldId_. This subtle difference results in translations of Specification Values created using the `vtex.catalog-graphql `app not being picked up during the indexing process.\n\n## Simulation\n\nFollow the guide about translation specification values: https://developers.vtex.com/docs/guides/catalog-internationalization\n\nCheck that the translation won't reflect on facets on the IS side.\n\n## Workaround\n\n- Get all Specification Values that you need to translate and their _FieldValueIds_.\n- Use the translated query to grab the current translation from the messages app using the _FieldId_ as context (in the example below, _Red_ is the Specification Value, and 1 is the _FieldId _for a Color specification).\n\n    query GetTranslation($args: TranslateArgs!) \\{translate(args: $args)\\}\\{\"args\": \\{ \"indexedByFrom\": [   \\{      \"from\": \"en-US\",      \"messages\": [        \\{          \"content\": \"Red\",          \"context\": \"1\"        \\}     ]    \\} ], \"to\": \"pt-BR\"\\}\\}\n\n- Create a new translation using the FieldValueId as context and the translate mutation (in the example below, 11 is the _FieldValueId_ for the Specification Value _Red_).\n\n    mutation Save($saveArgs: SaveArgsV2!) \\{saveV2(args: $saveArgs)\\}\\{\"saveArgs\": \\{ \"to\": \"pt-BR\", \"messages\": [   \\{      \"srcLang\": \"en-US\",      \"srcMessage\": \"Red\",      \"context\": \"11\",      \"targetMessage\": \"Vermelho\"    \\}]\\}\\}\nIn summary, instead of saving the \"context\" property based only on `fieldValueId`, you will also need to save it in the messages' context using the `fieldId`.\n\nNote that both translations are required since different parts of the store will use different ways to query it; the \"FieldValueId\" is used by the Catalog/Search information, and the \"FieldId\" may be used directly by the Store Framework.\n\nFor specification with type \"text\", whose values aren't predefined, there won't be an actual `fieldValueId`. In this case, the own text should be used, generating the same string in `srcMessage` and `context` fields."}