Implement GlossaryTerm React component per reviewer feedback

- Created GlossaryTerm.tsx component with hover tooltips
- Added GlossaryTerm.module.css for styling
- Updated glossary linker to output component format
- Uses placeholder system to prevent nested components
- Excludes :term[] directives, code blocks, and existing links
- Auto-adds import statements to modified files
- ~412 glossary links across 31 files

Author: solomon.legodi

tools/glossary_linker.py

@@ -212,6 +212,23 @@ def _split_frontmatter(self, content: str) -> Tuple[str, str]:
 
         return frontmatter, main_content
 
+    def _ensure_glossary_import(self, content: str) -> str:
+        """
+        Ensure the GlossaryTerm import is present after frontmatter.
+        Returns updated content with import if needed.
+        """
+        import_statement = "import GlossaryTerm from '@site/src/components/Glossary/GlossaryTerm';\n\n"
+        
+        # Check if import already exists
+        if "import GlossaryTerm" in content:
+            return content
+        
+        # Split frontmatter and main content
+        frontmatter, main_content = self._split_frontmatter(content)
+        
+        # Insert import after frontmatter
+        return frontmatter + import_statement + main_content
+    
     def _create_link_patterns(self, current_file: Path) -> List[Tuple]:
         """
         Create regex patterns for finding and replacing glossary terms.
@@ -319,6 +336,8 @@ def process_markdown_file(self, file_path: Path, dry_run: bool = False) -> Dict:
                 else:
                     # Apply patterns to text sections only
                     modified_content = section_content
+                    placeholders = {}  # Store placeholders
+                    placeholder_counter = 0
 
                     # Process each pattern
                     for pattern, canonical_term, slug, glossary_url in patterns:
@@ -332,13 +351,21 @@ def process_markdown_file(self, file_path: Path, dry_run: bool = False) -> Dict:
 
                                 # Check if we've already linked this term (case-insensitive check)
                                 if matched_text.lower() not in already_linked:
-                                    # Create link with MATCHED text (preserves original casing)
-                                    replacement = f'[{matched_text}]({glossary_url}#{slug})'
+                                    # Create GlossaryTerm component (preserves original casing)
+                                    # Format: <GlossaryTerm term={"canonical term"}>matched text</GlossaryTerm>
+                                    # Escape quotes in the term
+                                    escaped_term = canonical_term.replace('\\', '\\\\').replace('"', '\\"')
+                                    component = f'<GlossaryTerm term={{"{escaped_term}"}}>{matched_text}</GlossaryTerm>'
+                                    
+                                    # Use a placeholder that won't match any pattern
+                                    placeholder = f'___GLOSSARY_PLACEHOLDER_{placeholder_counter}___'
+                                    placeholders[placeholder] = component
+                                    placeholder_counter += 1
 
-                                    # Replace this specific occurrence
+                                    # Replace with placeholder
                                     modified_content = (
                                         modified_content[:match.start(1)] + 
-                                        replacement + 
+                                        placeholder + 
                                         modified_content[match.end(1):]
                                     )
 
@@ -352,11 +379,19 @@ def process_markdown_file(self, file_path: Path, dry_run: bool = False) -> Dict:
                                     # Mark as linked (case-insensitive)
                                     already_linked.add(matched_text.lower())
 
+                    # Replace all placeholders with actual components
+                    for placeholder, component in placeholders.items():
+                        modified_content = modified_content.replace(placeholder, component)
+                    
                     processed_sections.append(modified_content)
 
             # Reconstruct content with frontmatter
             new_content = frontmatter + ''.join(processed_sections)
 
+            # Add GlossaryTerm import if terms were linked
+            if stats['terms_linked'] > 0:
+                new_content = self._ensure_glossary_import(new_content)
+            
             # Only write if content changed and not a dry run
             if new_content != original_content and not dry_run:
                 with open(file_path, 'w', encoding='utf-8') as f:
@@ -425,8 +460,8 @@ def _split_content_sections(self, content: str) -> List[Tuple[str, str]]:
                 sections.append(('lo_block', '\n'.join(lo_block) + '\n'))
                 continue
 
-            # Check for inline code or existing links in the line
-            if '`' in line or '[' in line:
+            # Check for inline code, existing links, GlossaryTerm components, or :term[] directives in the line
+            if '`' in line or '[' in line or '<GlossaryTerm' in line or ':term[' in line:
                 # Split this line more carefully
                 processed_line = self._process_line_with_special_content(line)
                 sections.extend(processed_line)
@@ -441,14 +476,14 @@ def _split_content_sections(self, content: str) -> List[Tuple[str, str]]:
 
     def _process_line_with_special_content(self, line: str) -> List[Tuple[str, str]]:
         """
-        Process a line that may contain inline code or existing links.
+        Process a line that may contain inline code, existing links, GlossaryTerm components, or :term[] directives.
         Split it into linkable and non-linkable parts.
         """
         sections = []
         current_pos = 0
 
-        # Pattern to find inline code (`...`) or existing links ([...](...)
-        special_pattern = re.compile(r'(`[^`]+`|\[[^\]]+\]\([^\)]+\))')
+        # Pattern to find inline code (`...`), existing links ([...](...)  ), GlossaryTerm components, or :term[] directives
+        special_pattern = re.compile(r'(`[^`]+`|\[[^\]]+\]\([^\)]+\)|<GlossaryTerm[^>]*>.*?</GlossaryTerm>|:term\[[^\]]+\](?:\{[^}]+\})?)')
 
         for match in special_pattern.finditer(line):
             # Add text before the special content

website/docs/chapter-01/00_overview.md

@@ -1,3 +1,6 @@
+import GlossaryTerm from '@site/src/components/Glossary/GlossaryTerm';
+
 # 1 Introduction to Robot Framework
 
-The upcoming chapters provide a concise overview of Robot Framework, including its core structure, use cases in test automation and [Robotic Process Automation](/docs/glossary#robotic-process-automation) (RPA), and key specification styles like [keyword](/docs/glossary#keyword)-driven and behavior-driven testing. You'll learn about its architecture, syntax, and how [test cases](/docs/glossary#[test](/docs/glossary#test-case)-case) and [tasks](/docs/glossary#task) are organized. Additionally, the chapters explain the open-source licensing under Apache 2.0, the role of the [Robot Framework Foundation](/docs/glossary#robot-framework-foundation) in maintaining the ecosystem, and the foundational web resources available for further exploration and contributions.
+The upcoming chapters provide a concise overview of Robot Framework, including its core structure, use cases in <GlossaryTerm term={"Test Case"}>test</GlossaryTerm> automation and [Robotic Process Automation](/docs/glossary#robotic-process-automation) (RPA), and key specification styles like [keyword](/docs/glossary#keyword)-driven and behavior-driven testing. You'll learn about its architecture, syntax, and how [test cases](/docs/glossary#[test](/docs/glossary#test-case)-case) and [tasks](/docs/glossary#task) are organized. Additionally, the chapters explain the open-source licensing under Apache 2.0, the role of the [Robot Framework Foundation](/docs/glossary#robot-framework-foundation) in maintaining the ecosystem, and the foundational web resources available for further exploration and contributions.
+

website/docs/chapter-01/01_purpose.md

@@ -1,3 +1,5 @@
+import GlossaryTerm from '@site/src/components/Glossary/GlossaryTerm';
+
 # 1.1 Purpose / Use Cases
 
 ::::lo[Learning Objectives]
@@ -35,13 +37,13 @@ Robot Framework is widely used at various levels of testing, primarily focusing
 
 - **System Integration Testing**: Focuses on the interaction between the system under [test](/docs/glossary#test-case) and external services, as well as on the integration of multiple systems into a larger system, ensuring that all integrated components communicate and function together as expected.
 
-- **Acceptance Testing**: Aims to validate that the system meets business requirements and is ready for deployment or release. This often includes different forms of acceptance testing (e.g., user acceptance, operational acceptance, regulatory acceptance) and is frequently written or conducted by end-users or stakeholders to confirm the system’s readiness for use. Acceptance tests, often defined by business stakeholders in approaches like Acceptance Test-Driven Development (ATDD), can be automated and executed earlier in the development process. This ensures that the solution aligns with business requirements from the start and provides immediate feedback, reducing costly changes later.
+- **Acceptance Testing**: Aims to validate that the system meets business requirements and is ready for deployment or release. This often includes different forms of <GlossaryTerm term={"Acceptance Testing"}>acceptance testing</GlossaryTerm> (e.g., user acceptance, operational acceptance, regulatory acceptance) and is frequently written or conducted by end-users or stakeholders to confirm the system’s readiness for use. Acceptance tests, often defined by business stakeholders in approaches like Acceptance <GlossaryTerm term={"Test Case"}>Test</GlossaryTerm>-Driven Development (ATDD), can be automated and executed earlier in the development process. This ensures that the solution aligns with business requirements from the start and provides immediate feedback, reducing costly changes later.
 
 - **End-to-End Testing**: Verifies that a complete workflow or process within the system operates as intended, covering all interconnected subsystems, interfaces, and external components. [End-to-end tests](/docs/glossary#end-to-end-test) ensure the correct functioning of the application in real-world scenarios by simulating user interactions from start to finish.
 
 Robot Framework's flexibility and support for external libraries make it an excellent tool for automating these comprehensive [test cases](/docs/glossary#test-case), ensuring seamless interaction between components and validating the system's behavior also in production or production-like conditions.
 
-Robot Framework is typically not used for **component testing** nor **integration testing** because its primary strength lies in higher-level testing, such as system, acceptance, and end-to-end testing, where behavior-driven and keyword-based approaches excel. Component testing requires low-level, granular tests focusing on individual units of code, often necessitating direct interaction with the codebase, mocking, or stubbing, which are better handled by unit testing frameworks like JUnit, pytest, or NUnit. Similarly, integration testing at a low level often requires precise control over service interactions, such as API stubs or protocol-level testing, which may not align with Robot Framework's abstraction-oriented design. While Robot Framework can technically handle these cases through custom libraries, its overhead and design philosophy make it less efficient compared to tools specifically tailored for low-level and tightly scoped testing tasks.
+Robot Framework is typically not used for **component testing** nor **integration testing** because its primary strength lies in higher-level testing, such as system, acceptance, and end-to-end testing, where behavior-driven and <GlossaryTerm term={"Keyword"}>keyword</GlossaryTerm>-based approaches excel. Component testing requires low-level, granular tests focusing on individual units of code, often necessitating direct interaction with the codebase, mocking, or stubbing, which are better handled by unit testing frameworks like JUnit, pytest, or NUnit. Similarly, integration testing at a low level often requires precise control over service interactions, such as API stubs or protocol-level testing, which may not align with Robot Framework's abstraction-oriented design. While Robot Framework can technically handle these cases through custom libraries, its overhead and design philosophy make it less efficient compared to tools specifically tailored for low-level and tightly scoped testing <GlossaryTerm term={"Task"}>tasks</GlossaryTerm>.
 
 
 ### 1.1.1.1 Synthetic Monitoring
@@ -55,12 +57,13 @@ Beyond traditional [test levels](/docs/glossary#test-level), **Synthetic Monitor
 [Robotic Process Automation](/docs/glossary#robotic-process-automation) (RPA) uses software bots to perform tasks and interactions normally performed by humans, without requiring changes to the underlying applications.
 
 Robot Framework, with its keyword-driven approach, vast ecosystem of libraries, simplicity, and scalability, is widely adopted for [RPA](/docs/glossary#robotic-process-automation) tasks.
-Robot Framework allows users to automate most workflows using ready-made keyword libraries that provide a wide range of functionalities. These libraries can be combined and reused in user-defined [keywords](/docs/glossary#keyword), making automation simple and efficient. For custom functionalities or more complex tasks, Robot Framework also offers the flexibility to create custom keyword libraries using Python, enabling advanced use cases and seamless integration with unique systems.
+Robot Framework allows users to automate most workflows using ready-made <GlossaryTerm term={"Keyword Library"}>keyword libraries</GlossaryTerm> that provide a wide range of functionalities. These libraries can be combined and reused in user-defined [keywords](/docs/glossary#keyword), making automation simple and efficient. For custom functionalities or more complex tasks, Robot Framework also offers the flexibility to create custom keyword libraries using Python, enabling advanced use cases and seamless integration with unique systems.
 
-Common use cases of RPA with Robot Framework include:
+Common use cases of <GlossaryTerm term={"Robotic Process Automation"}>RPA</GlossaryTerm> with Robot Framework include:
 
 - **Data extraction and manipulation**: Automating data transfers and processing between systems.
 - **Task / Process automation**: Automating tasks such as form submissions, clicks, and file operations across web or desktop applications.
 
 
 
+

website/docs/chapter-01/02_architecture.md

@@ -1,3 +1,5 @@
+import GlossaryTerm from '@site/src/components/Glossary/GlossaryTerm';
+
 # 1.2 Architecture of Robot Framework
 
 Robot Framework is an open-source automation framework that allows you to build [automation scripts](/docs/glossary#automation-script) for testing and [RPA](/docs/glossary#robotic-process-automation) (Robotic Process Automation).
@@ -19,22 +21,22 @@ Recall the layers of the Generic Test Automation Architecture (gTAA) and their c
 
 ::::
 
-The **Generic Test Automation Architecture (gTAA)** described in the ISTQB "Certified Tester Advanced Level Test Automation Engineering" offers a structured approach to [test](/docs/glossary#test-case) automation, dividing it into different layers for a clear separation of concerns:
+The **Generic Test Automation Architecture (gTAA)** described in the ISTQB "Certified Tester Advanced Level <GlossaryTerm term={"Test Case"}>Test</GlossaryTerm> Automation Engineering" offers a structured approach to [test](/docs/glossary#test-case) automation, dividing it into different layers for a clear separation of concerns:
 
-- **Definition Layer**: This layer contains the "[Test Data](/docs/glossary#test-data)" ([test cases](/docs/glossary#test-case), tasks, [resource files](/docs/glossary#resource-file) which include [user keywords](/docs/glossary#user-keyword) and variables).
-In Robot Framework, the test data is written using the defined syntax and contains keyword calls and [argument](/docs/glossary#argument) values that make the [test case](/docs/glossary#test-case) or [task](/docs/glossary#task) definitions structured in suites.
+- **Definition Layer**: This layer contains the "[Test Data](/docs/glossary#test-data)" ([test cases](/docs/glossary#test-case), <GlossaryTerm term={"Task"}>tasks</GlossaryTerm>, [resource files](/docs/glossary#resource-file) which include [user keywords](/docs/glossary#user-keyword) and variables).
+In Robot Framework, the <GlossaryTerm term={"Test Data"}>test data</GlossaryTerm> is written using the defined syntax and contains <GlossaryTerm term={"Keyword"}>keyword</GlossaryTerm> calls and [argument](/docs/glossary#argument) values that make the [test case](/docs/glossary#test-case) or [task](/docs/glossary#task) definitions structured in suites.
 
 - **Execution Layer**: In Robot Framework, the [execution layer](/docs/glossary#execution-layer) consists of the framework itself, including its core components and APIs.
 It parses and interprets the test data syntax to build an [execution model](/docs/glossary#execution-model).
-The execution layer is responsible for processing this execution model to execute the library [keywords](/docs/glossary#keyword) with their argument values, logging results, and generating reports.
+The <GlossaryTerm term={"Execution Layer"}>execution layer</GlossaryTerm> is responsible for processing this <GlossaryTerm term={"Execution Model"}>execution model</GlossaryTerm> to execute the library [keywords](/docs/glossary#keyword) with their <GlossaryTerm term={"Argument"}>argument</GlossaryTerm> values, logging results, and generating reports.
 
 - **Adaptation Layer**: This layer provides the connection between Robot Framework and the system under test (SUT).
 In Robot Framework, this is where the [keyword libraries](/docs/glossary#keyword-library), which contain code responsible for interacting with different technologies and interfaces,
 such as those for UI, API, database interactions, or others, are located.
-These keyword libraries enable interaction with different technologies and interfaces, ensuring the automation is flexible and adaptable to various environments.
+These <GlossaryTerm term={"Keyword Library"}>keyword libraries</GlossaryTerm> enable interaction with different technologies and interfaces, ensuring the automation is flexible and adaptable to various environments.
 
 Editors/IDEs that offer support for Robot Framework's syntax are tools that support or integrate in these layers.
-When writing tests|tasks or keywords, the editor supports the [definition layer](/docs/glossary#definition-layer).
+When writing tests|tasks or <GlossaryTerm term={"Keyword"}>keywords</GlossaryTerm>, the editor supports the [definition layer](/docs/glossary#definition-layer).
 When executing or debugging tests|tasks, the editor supports the execution layer.
 When writing keywords in e.g. Python for keyword libraries, the editor supports the [adaptation layer](/docs/glossary#adaptation-layer).
 Therefore also other additional extensions of Robot Framework can be categorized into these layers.
@@ -54,7 +56,7 @@ Recall what is part of Robot Framework and what is not
 ::::
 
 
-Robot Framework itself focuses primarily on **test|task execution**.
+Robot Framework itself focuses primarily on **test|<GlossaryTerm term={"Task"}>task</GlossaryTerm> execution**.
 It includes:
 
 - A parser to read test|task data and build an execution model.
@@ -65,7 +67,7 @@ It includes:
 
 However, Robot Framework **does not** include:
 
-- Keyword libraries to control systems under test/RPA.
+- Keyword libraries to control systems under test/<GlossaryTerm term={"Robotic Process Automation"}>RPA</GlossaryTerm>.
 
   Such as:
   - Web front-end automation libraries.
@@ -103,3 +105,4 @@ Robot Framework itself does not have any external dependencies, but additional t
 
 
 
+