fix: use gt hydration error

[ErnestM1234]

No description provided.

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
gt-docs	🔄 Building (Inspect)	Visit Preview	💬 Add feedback	Jul 30, 2025 11:24pm

5 Skipped Deployments

Name	Status	Preview	Comments	Updated (UTC)
example-ai-chatbot	⬜️ Ignored (Inspect)			Jul 30, 2025 11:24pm
example-create-react-app	⬜️ Ignored (Inspect)			Jul 30, 2025 11:24pm
example-gt-next-starter	⬜️ Ignored (Inspect)			Jul 30, 2025 11:24pm
example-next-create-app	⬜️ Ignored (Inspect)			Jul 30, 2025 11:24pm
example-vite-create-app	⬜️ Ignored (Inspect)			Jul 30, 2025 11:24pm

[greptile-apps]

Greptile Summary

This PR fixes React hydration errors in the General Translation (GT) library by ensuring consistent initialization of translation status between server-side rendering and client-side hydration. The changes introduce proper handling of initialTranslationsStatus throughout the provider chain.

The fix addresses a common SSR hydration issue where server-rendered content must exactly match client-side initial render. Previously, the translationsStatus state was initialized differently on server vs client, causing React to detect DOM mismatches during hydration. The solution follows the existing pattern used for translations state.

Key changes include:

• Adding initialTranslationsStatus field to ClientProviderProps type definition with proper TranslationsStatus import
• Modifying the Next.js GTProvider to fetch and pass cached translation status to the client provider
• Updating ClientProvider to conditionally initialize translationsStatus state using server-provided data in production, while maintaining null initialization in development mode (when devApiKey is present)

This follows the established architectural pattern where server-side providers prepare initial state data and pass it to client-side providers for consistent hydration. The fix maintains backward compatibility and respects the development vs production environment distinctions already present in the codebase.

Confidence score: 5/5

• This PR is very safe to merge and addresses a clear hydration bug with a well-established solution pattern
• The implementation follows existing patterns in the codebase and maintains proper type safety and backward compatibility
• No files need additional attention - the changes are straightforward and consistent across the provider chain

_{3 files reviewed, 1 comment}

_{Edit Code Review Bot Settings | Greptile}

[greptile-apps]

style: The type assertion ({} as any) bypasses type safety. Consider using ({} as TranslationsStatus) for better type safety.

Suggested change

	: ({} as any);
	: ({} as TranslationsStatus);