Front-end multilingual error prompt method

Abstract

This application provides a front-end multilingual error message method. The method includes: a front-end HTTP service layer receiving a response message sent by a back-end electronic device, the response message being the back-end electronic device's response to an HTTP request received by the front-end business layer; if the front-end business layer has not configured an error ignore flag, extracting a first error code from the response message; if the first error code does not match any error code flag in an error code mapping table, obtaining an error field from the first error code; if the error field in the first error code is empty, obtaining an HTTP response status code, wherein the HTTP response status code is a status code in response to a response message; and if the status code does not match a preset status code, outputting a first message matching the front-end system language flag.

Description

Technical Field

[0001] This application relates to the field of web front-end application information processing technology, specifically to a front-end multilingual error message method. Background Technology

[0002] Currently, the main problems with multilingual error messages in web front-end applications are as follows: When encountering various abnormal scenarios such as unmapped error codes, non-standard error messages returned by the backend, and network timeouts, there is a lack of a complete multi-level fallback chain to ensure users always receive meaningful prompts. The mapping relationship between error codes and multilingual text is scattered across different locations, making unified management, auditing, and updating difficult. There is a lack of a flexible balance mechanism between unified processing and business customization; either all unified processing fails to meet specific business needs, or all manual processing is inefficient. Summary of the Invention

[0003] The purpose of this application is to provide a front-end multilingual error message method, and the specific technical solution adopted is as follows: Firstly, a method for displaying multilingual error messages on a front-end is provided, the method comprising: The Hypertext Transfer Protocol (HTTP) service layer set up at the front end obtains response messages sent by the back-end electronic device. The response message is the response of the back-end electronic device to the HTTP request sent by the front-end business layer. If it is determined that the front-end business layer has not configured an error ignore flag, the first error code is extracted from the response message; If it is determined that the first error code does not match any error code identifier in the error code mapping table, the error field in the first error code is obtained; If the error field in the first error code is determined to be empty, the HTTP response status code is obtained, wherein the HTTP response status code is a status code in response to the response message; If it is determined that the status code does not match the preset status code, a first prompt message matching the front-end system language identifier is output.

[0004] Secondly, a front-end multilingual error prompting device is provided, the device comprising: The first acquisition module is used to acquire response messages sent by the backend electronic device through the Hypertext Transfer Protocol (HTTP) service layer set at the front end. The response message is the response of the backend electronic device to the HTTP request sent by the front end business layer. The extraction module is used to extract the first error code from the response message if the front-end business layer is not configured with an error ignore flag. The second acquisition module is used to acquire the error field in the first error code when it is determined that the first error code does not match any error code identifier in the error code mapping table. The third acquisition module is used to acquire an HTTP response status code when the error field in the first error code is empty, wherein the HTTP response status code is a status code in response to the response message. The output module is used to output a first prompt message that matches the language identifier of the front-end system when it is determined that the status code does not match the preset status code.

[0005] Thirdly, an electronic device is provided, comprising: a memory and at least one processor, wherein the memory stores instructions; the at least one processor invokes the instructions in the memory to cause the electronic device to execute the aforementioned method for displaying multilingual error messages.

[0006] Fourthly, a computer program product is provided, comprising: computer program code, which, when run on a computer, causes the computer to perform the methods described in the first aspect or any possible implementation thereof.

[0007] Fifthly, a computer-readable storage medium is provided that stores computer program code, which, when executed on a computer, causes the computer to perform the methods described in the first aspect or any possible implementation thereof.

[0008] This application offers the following advantages: Through a structured error handling process, it automates the transition from backend errors to user-friendly frontend prompts, while also supporting adaptive prompts in multilingual environments, effectively improving user experience and system maintainability. A four-level degradation chain ensures reasonable user prompts for all possible error scenarios. Setting the error ignore flag "$ignoreErro" parameter implements a flexible mechanism for skipping errors on demand, ensuring consistent processing efficiency for most scenarios while also meeting the customized needs of specific business scenarios. The mapping table facilitates maintenance and auditing, and also allows for batch translation additions when new languages ​​are added. Attached Figure Description

[0009] To more clearly illustrate the technical solutions and advantages in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0010] Figure 1 This application provides a schematic diagram of a multilingual error message system for a web front-end. Figure 2 A schematic diagram illustrating the implementation flow of the degradation chain processing method provided in this application embodiment; Figure 3 A flowchart illustrating a front-end multilingual error message method provided in an embodiment of this application; Figure 4 A schematic diagram of a front-end multilingual error display device provided in an embodiment of this application; Figure 5 This is a schematic diagram of the structure of a computer device provided in an embodiment of this application. Detailed Implementation

[0011] To further illustrate the technical means and effects adopted by this application to achieve the intended inventive purpose, the following, in conjunction with the accompanying drawings and preferred embodiments, details the specific implementation, structure, features, and effects of a front-end multilingual error prompting method proposed in this application. In the following description, different "one embodiment" or "another embodiment" do not necessarily refer to the same embodiment. Furthermore, specific features, structures, or characteristics in one or more embodiments can be combined from any suitable form.

[0012] In the description of the embodiments of this application, unless otherwise stated, " / " means "or". For example, A / B can mean A or B. The "and / or" in the text is merely a description of the relationship between related objects, indicating that there can be three relationships. For example, A and / or B can mean: A exists alone, A and B exist simultaneously, and B exists alone. In addition, in the description of the embodiments of this application, "multiple" means two or more.

[0013] Hereinafter, the terms "first" and "second" are used for descriptive purposes only and should not be construed as implying or suggesting relative importance or implicitly indicating the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature.

[0014] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application pertains.

[0015] Currently, the main methods for handling multilingual error messages from backend interfaces in web front-end applications are as follows: 1. Backend returns translated error messages: The backend directly returns the translated error message text based on the language identifier in the request header. The disadvantages of this method are: the backend needs to maintain a separate error message for each language, increasing its maintenance burden; adding a new language requires modifying the backend code and redeploying; for Internet of Things (IoT) embedded devices, backend storage resources are limited, and storing error messages in multiple languages ​​will consume valuable device storage space.

[0016] 2. Decentralized processing in the front-end business layer: Each front-end business module uses if-else or switch-case statements in its own API call code to check the error code, manually find the corresponding multilingual keywords, and display them. The disadvantages of this approach are: error handling logic is scattered across various business modules, resulting in high code duplication; adding new error codes requires synchronously adding processing logic to all relevant modules, making omissions easy; and inconsistent handling methods among different developers lead to inconsistent user experiences.

[0017] 3. Front-end global interception without fallback mechanism: Errors are handled uniformly in the HTTP interceptor, but for unrecognized error codes, the original error message or general error message is displayed directly. This approach lacks a multi-level fallback strategy, and users either see incomprehensible technical error messages or overly general prompts that fail to help them locate the problem.

[0018] 4. Third-party internationalization platform approach: This method relies on cloud-based translation platforms or large-scale translation services for managing and translating erroneous text. This approach depends on network connectivity, is unsuitable for IoT devices deployed on a local area network, and introduces reliance on external services and associated costs.

[0019] This application provides a web front-end multilingual error message system, such as... Figure 1 As shown, the system is deployed in the front-end HTTP service layer, where, Front-end business layer controllable skip mechanism: The business layer can flexibly control whether to skip unified error handling through the "$ignoreError" parameter. Business A can configure: `$ignoreError = ['E01']`, which is an error ignoring configuration item. Only specified error codes are skipped from the unified processing and handled by the business itself. Business A can configure an array of error codes. When an HTTP request returns an error code in this array, Business A will ignore these errors without performing any additional error handling or displaying any error messages. For example, when the returned error code is E01, Business A considers it an ignoreable error and will not interrupt the business process or display an error message to the user.

[0020] In some embodiments, the configuration string array [xxx, xxx] indicates that only the specified error codes are skipped from the unified processing and are handled by the business logic itself.

[0021] Configuration string xxx: Specifies a single error code to skip unified processing.

[0022] Business B can configure: `$ignoreError = false`. This configuration item indicates whether Business B ignores errors. Setting it to false means that all errors from Business B will skip the unified prompts and be handled entirely by the business itself. It will not ignore any errors returned by HTTP requests, and all errors will be handled according to the default error handling process, which may display error prompts to the user or execute corresponding error recovery logic.

[0023] Business C defaults to a unified approach. Since Business C does not explicitly configure the `$ignoreError` parameter, it adopts the default unified error fallback chain handling method. This means that Business C's error handling logic will follow the HTTP service layer or the application's overall error fallback chain handling strategy, and will not perform special handling for specific error codes.

[0024] By configuring `$ignoreError`, different business units can flexibly handle errors according to their own business needs. For example, business unit A may ignore certain specific errors that do not affect the business process, while business unit B wants to strictly handle all errors to ensure the correctness and stability of the business.

[0025] Placing error handling configurations at the business level facilitates unified management and maintenance. When error handling strategies need to be adjusted, only the configuration of the corresponding business function needs to be modified, without requiring extensive changes to the business code.

[0026] They may undertake different business functions, and their error handling methods may also differ. A configurable approach allows for better adaptation to various complex business scenarios, improving the system's flexibility and scalability.

[0027] The HTTP service layer consists of three parts: 1. Request interceptor 11 can achieve the following functions: Add the language identifier (Accept-Language) to the request header; Add the user token to the request header; The request parameters are signed to prevent tampering.

[0028] 2. The Response Handler 12 processing logic is divided into two branches based on whether the business logic is configured to skip: Left branch: If the configuration skips, "Return to business layer for processing". This means that if the business is configured to skip, the response interceptor will directly return the response to the business layer, which will then process the response itself.

[0029] The right-hand branch states: "If the configuration does not skip, proceed to the fallback chain for processing (see section 3.2 Fallback Chain)". This means that if the service is not configured to skip, the response will be processed through the fallback chain. For details on the fallback chain, please refer to section 3.2 of the document.

[0030] Error code mapping table (error_keys_map.json) 13 displays the specific contents of the error code mapping table. The mapping table is presented in JSON format and contains multiple error codes and their corresponding descriptions, for example: json { "1001": "error.auth.token_expired", "1002": "error.auth.permission_denied", "2001": "error.network.timeout", ... } Each error code (such as "1001", "1002", "2001") corresponds to a specific error description string, which can be used to display user-friendly error messages on the front end.

[0031] "Multilingual Resources (locales)"14 lists resource examples in two languages: en-US: "error.auth.token_expired": "Session expired, please login": This means that in an American English (en-US) language environment, when an error occurs indicating that the authentication token has expired (error code error.auth.token_expired), the message displayed to the user is "Session expired, please log in".

[0032] zh-CN: "error.auth.token_expired": "Session expired, please log in again": This means that in a Simplified Chinese (zh-CN) language environment, when the same authentication token expires, the message displayed to the user is "Session expired, please log in again".

[0033] Unified handling of session expiration: The front-end service layer handles session expiration error codes in a special way: after detecting session expiration, it will redirect to the login page in a unified manner, without the business layer needing to pay attention to session management logic.

[0034] This application provides a method for automating multilingual error messages in a web front-end, which can be achieved through the following steps: Step S21: Send the request; When the business layer initiates an HTTP request, the service layer request interceptor automatically injects the current system language identifier (such as "Accept-Language:en") into the request header and carries the user token. It also performs deduplication on duplicate requests with the same unique value.

[0035] Language identifier injection: The current system language (such as en) is automatically injected into the Accept-Language header through the request interceptor to ensure that the content returned by the backend matches the user's language preference.

[0036] Token carrying: Read the user's token from local storage (such as localStorage), inject the Authorization header, and realize identity authentication.

[0037] Deduplication of duplicate requests: Cache requests based on unique request identifiers (such as URL + parameter hash + request method). If the same request is found to be in progress, directly reuse the Promise of the previous request to avoid sending it repeatedly.

[0038] Step S22: Response reception and skip determination; Upon receiving the response, the service layer response interceptor first checks whether the business layer has configured the "$ignoreError" parameter: If configured as "false", no unified processing will be performed, and the response will be directly returned to the business layer; If configured as an array / string of error codes, then matching error codes will be skipped and processed uniformly. If not configured, proceed to the degradation chain processing (steps S23 to S26).

[0039] Figure 2 This is a schematic diagram illustrating the implementation flow of the degradation chain processing method provided in the embodiments of this application, as follows: Figure 2 As shown, the downgrade training process can be achieved through the following steps: Step S23: Error code mapping lookup (downgrade level 1); Extract the error code from the API response and look up the corresponding multilingual copywriting keywords (keys) in the "error_keys_map.json" mapping table.

[0040] If a mapping is found, the translated text is retrieved from multilingual resources based on the current system language and displayed to the user. If no mapping is found, the process proceeds to the next level (step S24).

[0041] The arrow on the right points to "OK", indicating successful processing; the arrow below points to the next level, indicating the process flow when no mapping is found.

[0042] In some embodiments, error code grouping mapping is also provided: in addition to one-to-one mapping, error code range mapping can be supported (such as uniformly mapping error codes 1000-1099 to the "authentication-related error" category), reducing the maintenance workload of the mapping table.

[0043] In some embodiments, dynamic mapping table loading is also provided: the mapping table does not need to be hardcoded in the front-end code, but can be dynamically obtained from the back-end and cached, supporting the real-time addition of error code mappings without updating the front-end version.

[0044] In some embodiments, error code context enhancement is also provided: parameterized template text (such as "error.file.size_exceeded": "file size exceeds {maxSize} MB limit") is supported in the mapping table, and the service layer automatically fills the text template with the parameters returned by the backend, providing more accurate error messages.

[0045] In some embodiments, error message style hierarchy is also provided: based on the severity of the error code (e.g., by distinguishing by error code prefix or range), different message styles (e.g., normal message, warning pop-up, full-screen error page) are automatically selected to achieve automatic matching between message style and error severity.

[0046] In some embodiments, error code usage statistics and coverage warnings are also provided: by recording the level of each degradation chain hit in the service layer, the error codes entering the 2nd / 3rd / 4th level degradation are automatically counted, and an "unmapped error code list" is generated to help developers supplement the mapping relationship in a timely manner and gradually improve the coverage of the 1st level.

[0047] Step S24: Original error message (downgraded to level 2); If the error code is not found in the mapping table, check if the error field of the response contains a non-empty error text. If so, display the error text directly to the user as a prompt (unless "$ignoreErrorText" is configured). If the error field is empty, proceed to the next level of processing (step S25).

[0048] No translation is required; this is used for non-standard format interfaces that have already been processed by the backend.

[0049] The arrow on the right points to "OK", indicating successful processing; the arrow below points to the next level, indicating the process flow when no mapping is found.

[0050] Step S25: HTTP status code identification (downgrade level 3); If the error field is empty, check the HTTP response status code. The HTTP response status code returned by the browser comes from the status field in the HTTP request-response (Response) information. If it is 408 or 504, display a "Request Timed Out" message in multiple languages.

[0051] If the corresponding status code is detected, the process ends (the arrow on the right points to "OK").

[0052] If the corresponding status code is not identified, proceed to the next level of processing (step S26).

[0053] Step S26: General fallback tip (downgraded to level 4); If none of the above conditions are met, use a generic multilingual message for "Service Error" (translated using multiple semantic keys) to ensure that users do not see blank or technical error messages.

[0054] Note: Each level can terminate the downgrade and display a prompt; if a session expiration error code is detected, proceed to step S27: any level will directly redirect to the login page.

[0055] Step S27: Session expiration handling.

[0056] If an error code indicating session expiration is detected during any level of the downgrade process, the downgrade chain is interrupted, and the user is redirected directly to the login page.

[0057] The service layer interception provided in this application embodiment is seamless for the business layer: Unlike existing solutions that handle error codes in a decentralized manner at the business layer, this solution completely converges the multilingual mapping and prompting logic of error codes to the HTTP service layer. Business developers do not need to pay attention to error code handling, achieving "zero-configuration" multilingual error prompting.

[0058] The four-level degradation chain provided in this application guarantees 100% coverage: Existing solutions typically only handle known error codes and lack the ability to handle responses to unknown error codes or abnormal formats. This solution, through a four-level degradation chain, ensures that all possible error scenarios have reasonable user prompts.

[0059] This application provides a flexible balance between unified processing and customization: existing solutions often offer a choice between fully unified or fully manual processing. This solution implements a flexible mechanism of skipping on demand through the "$ignoreErro" parameter, ensuring unified processing efficiency in most scenarios while meeting the customization needs of special business scenarios.

[0060] The centralized mapping table provided in this application embodiment facilitates maintenance and auditing: the mapping relationship between error codes and multilingual text is centralized in a JSON file, which facilitates unified maintenance, auditing and version management, and also facilitates batch translation when adding new languages.

[0061] The four core technical points and corresponding technical effects provided in this application are as follows: Technical point 1: Automated multilingual error prompts driven by a unified error code mapping table.

[0062] A centralized "error_keys_map.json" error code mapping table is maintained at the HTTP service layer, establishing a one-to-one mapping between the numeric / string error codes returned by the backend interface and the multilingual text keys on the frontend. After receiving the interface response, the service layer interceptor automatically looks up the table, retrieves the language pack, and displays the translated text, without any intervention from the business layer.

[0063] The technical effects are as follows: When adding a new error code, simply add a mapping relationship to the mapping table and add the corresponding text to the language pack, and it will automatically take effect in all business modules without modifying any business code.

[0064] Business developers are "unaware" of error codes, allowing them to focus on business logic development and significantly improve development efficiency.

[0065] Error message behavior is consistent globally, ensuring a uniform user experience.

[0066] Technical point 2: Fault tolerance error prompting mechanism of four-level degradation chain.

[0067] A four-level degradation chain (error code mapping → original error text → HTTP status code recognition → fallback general prompt) was designed as shown in Table 1 below to ensure that users can obtain meaningful prompt information in any abnormal scenario.

[0068] Table 1

[0069] Technical effects: Even in various edge scenarios such as when backend error codes are not yet included in the mapping table, when backend interface formats are not standardized, or when network timeouts occur, the system can still provide reasonable error messages, greatly improving the system's robustness and user experience.

[0070] Technical point 3: A flexible control mechanism for skipping business layers as needed.

[0071] The "$ignoreError" parameter provides fine-grained business-level control capabilities, supporting three modes: "process all errors uniformly," "skip some error codes," and "skip all errors." This resolves the conflict between uniform processing and business customization.

[0072] Technical effects: For situations where the same error code requires different prompts in different business scenarios (e.g., the "insufficient permissions" error code needs to display detailed permission descriptions on the management page, while only a simple prompt is needed on a regular page), the business layer can precisely specify to skip the unified processing of specific error codes and provide customized prompts, while other error codes still enjoy the convenience of unified processing.

[0073] Technical point 4: Automatic language injection in request headers and multi-language linkage between front-end and back-end.

[0074] The service layer request interceptor automatically injects the current system language identifier into the request header (such as "Accept-Language") in each request, enabling the backend to perceive the current language environment of the frontend. This provides support for scenarios where the backend needs to return specific language content (such as filenames, exported content, etc.), and achieves automatic synchronization of multi-language states between the frontend and backend.

[0075] Figure 3 This is a flowchart illustrating a front-end multilingual error message method provided in an embodiment of this application, as shown below. Figure 3 As shown, this can be achieved through the following steps: Step S310: The Hypertext Transfer Protocol (HTTP) service layer set on the front end obtains the response message sent by the back end electronic device, wherein the response message is the response of the back end electronic device to the HTTP request sent by the front end business layer. The business layer initiates an HTTP request, such as Figure 1The HTTP service layer request interceptor 11 automatically injects the current system language identifier (such as "Accept-Language:en") into the request header and carries the user token. It also performs deduplication on duplicate requests with the same unique value.

[0076] After receiving an HTTP request, the backend electronic device that communicates with the frontend sends a response message to the frontend system.

[0077] Step S320: If it is determined that the front-end business layer has not configured an error ignore flag, extract the first error code from the response message; Upon receiving the response, the service layer's response interceptor 11 first checks whether the business layer has configured the "$ignoreError" parameter.

[0078] If it is determined that the front-end business layer has not configured an error ignore flag, then proceed to the fallback chain for processing. That is, as follows: Figure 1 The default setting for business C is unified processing. Business C does not explicitly configure the $ignoreError parameter, therefore it adopts the default unified error degradation chain processing method. This means that the error handling logic of business C will follow the error degradation chain processing strategy of the HTTP service layer or the application as a whole, and will not perform special processing for specific error codes.

[0079] Step S330: If it is determined that the first error code does not match any error code identifier in the error code mapping table, obtain the error field in the first error code; During implementation, such as Figure 2 Step S23 (Degradation Level 1) shown: Extract the first error code from the interface response and look up the corresponding multilingual copywriting keyword (key) in the "error_keys_map.json" mapping table (error code mapping table).

[0080] If the error code is not found in the mapping table, retrieve the error fields included in the first error code.

[0081] Step S340: If the error field in the first error code is empty, obtain the HTTP response status code, wherein the HTTP response status code is a status code in response to the response message; like Figure 2 As shown in step S24 (degradation level 2), if the error code is not found in the mapping table, check if the error field of the response contains a non-empty error text. If the error field is empty, proceed to the next level of processing.

[0082] Step S25 (Degradation to Level 3): If the error field is empty, check the HTTP response status code. The HTTP response status code originates from the status field in the HTTP request response information. Common timeout status codes include: 408: Request Timeout, 504: Gateway Timeout.

[0083] Step S350: If it is determined that the status code does not match the preset status code, output a first prompt message that matches the front-end system language identifier.

[0084] like Figure 2 In step S26 (downgrade to level 4), if the corresponding preset status code is not recognized, a preset first prompt message is used, such as the general multilingual text "service error" (using multi-semantic key translation), to ensure that the user does not see blank or technical error messages.

[0085] In this embodiment, a structured error handling process automates the transition from backend errors to user-friendly frontend prompts, while also supporting adaptive prompts in multilingual environments, effectively improving user experience and system maintainability. A four-level degradation chain ensures reasonable user prompts for all possible error scenarios. Setting the error ignore flag "$ignoreErrone" parameter implements a flexible mechanism for skipping errors on demand, ensuring consistent processing efficiency for most scenarios while also meeting the customized needs of specific business scenarios. The mapping table facilitates maintenance and auditing, and also allows for batch translation additions when new languages ​​are added.

[0086] In some embodiments, after "obtaining the response message sent by the backend electronic device" in step S310, the frontend multilingual error message method can also be implemented through the following steps: Step A: If it is determined that the error ignore flag of the front-end business layer is configured to a first preset value, the first preset value is used to instruct the HTTP service layer not to uniformly process the error codes in the response message; Step B: Return the response message to the front-end business layer; Step C: The front-end business layer obtains the second error code in the response message and executes the second output operation corresponding to the second error code.

[0087] like Figure 1 The configuration option for business B is: `$ignoreError = false`. This option indicates whether business B ignores errors. Setting it to false means that all errors from business B will skip the unified prompts and be handled entirely by the business itself. It will not ignore any errors returned by HTTP requests, and all errors will be handled according to the default error handling process, which may involve displaying error messages to the user or executing corresponding error recovery logic.

[0088] In this embodiment of the application, by configuring the error ignore flag to a first preset value, flexible customization of error handling is achieved: avoiding excessive intervention of the unified process in business errors, allowing the business layer to design error prompts and recovery logic according to its own needs; complementing the unified processing process, supporting business-specific error handling needs.

[0089] In some embodiments, after "obtaining the response message sent by the backend electronic device" in step S310, the frontend multilingual error message method can also be implemented through the following steps: Step A: If it is determined that the error ignore flag configuration of the front-end business layer includes a string array, the string array is used to match the error code in the response message; Step B: Determine that a third error code in the response message matches the string set in the string array; Step C: Return the third error code to the front-end business layer; Step D: The front-end business layer executes the third output operation corresponding to the third error code based on the third error code.

[0090] like Figure 1 The example shown shows that business A can be configured with `$ignoreError = ['E01']`, which is an error ignoring configuration item. Only specified error codes are skipped from the unified processing and handled by the business itself. Business A can configure an array of error codes. When an HTTP request returns an error code in this array, business A will ignore these errors without performing any additional error handling or displaying any error messages. For example, when the returned error code is E01, business A considers it an ignoreable error and will not interrupt the business process or display an error message to the user.

[0091] In some embodiments, the configuration string array [xxx, xxx] indicates that only the specified error codes are skipped from the unified processing and are handled by the business logic itself.

[0092] Configuration string xxx: Specifies a single error code to skip unified processing.

[0093] In this embodiment of the application, by configuring the error ignore flag as a string array, flexible customization of error handling is achieved: avoiding excessive intervention of the unified process in business errors, allowing the business layer to design error prompts and recovery logic according to its own needs; complementing the unified processing process, supporting business-specific error handling needs.

[0094] In some embodiments, the front-end multilingual error message method can also be implemented through the following steps: Step S360: If it is determined that the first error code matches any error code identifier in the error code mapping table, output a second prompt message corresponding to the first error code, wherein the second prompt message matches the front-end system language identifier.

[0095] like Figure 2 In step S23 (downgrade level 1), if the first error code is matched in the error code mapping table, the translated text is retrieved from multilingual resources according to the current system language and displayed to the user. The arrow on the right points to "OK", indicating successful processing.

[0096] In this embodiment, efficient conversion from error codes to user-friendly prompts is achieved, while providing flexible support for multilingual scenarios. Error logic is managed uniformly through an error code mapping table, avoiding hard-coding.

[0097] In some embodiments, the step S360 above, "when it is determined that the first error code matches any error code identifier in the error code mapping table, outputting the second prompt message corresponding to the first error code", can be achieved through the following steps: Step 361: Determine whether the first error code matches the error code template with preset parameters set in the error code mapping table; During implementation, error code context enhancements are also provided: parameterized template text is supported in the mapping table (e.g., "error.file.size_exceeded": "File size exceeds {maxSize} MB limit"). Step 362: Fill the error code template with the first parameter that matches the preset parameter in the error code template. During implementation, the service layer automatically fills the text template with the parameters returned by the backend. For example, it fills the template with the obtained file size maxSize of 10.

[0098] Step 363: Output the error code template with completed parameter filling as the second prompt message.

[0099] During implementation, a second prompt message can be output stating "File size exceeds 10MB limit".

[0100] In this embodiment, the service layer automatically populates the text template with parameters returned from the backend, providing more precise error messages. Providing specific error information (such as file size limits) through parameter population avoids generic error messages. This achieves dynamic error messages with parameters, improving the accuracy of error information while maintaining flexibility in multilingual scenarios, representing an enhanced feature in front-end multilingual error message solutions.

[0101] In some embodiments, the front-end multilingual error message method can also be implemented through the following steps: Step S370: If the error field in the first error code is determined to be a non-empty error text, the error text is output as a third prompt message.

[0102] like Figure 2 Step 24 (Degradation Level 2) shows that if the error field in the first error code is determined to be non-empty, the error text is directly displayed to the user as a prompt without translation, and is used for non-standard format interfaces already processed by the backend. The arrow on the right points to "OK", indicating successful processing.

[0103] In this embodiment, flexible handling of non-standard error formats is achieved, which not only ensures the accuracy of error information but also improves the efficiency of error prompts. It is an important supplementary mechanism in front-end multilingual error prompting schemes.

[0104] In some embodiments, the front-end multilingual error message method can also be implemented through the following steps: Step S380: If it is determined that the status code matches the preset status code, output a fourth prompt message based on the preset status code.

[0105] like Figure 2 Step S25 (Degradation Level 3) shows checking the HTTP response status code returned by the browser, which comes from the status field in the HTTP request-response information. If it is 408 or 504, then use a multilingual message "Request Timed Out" to indicate this.

[0106] If the corresponding status code is detected, the process ends (the arrow on the right points to "OK").

[0107] In this embodiment, standard HTTP status codes are used to reduce the maintenance workload of custom error codes. Users can clearly understand the reason for the timeout through the fourth prompt information and receive operation guidance, improving problem-solving efficiency.

[0108] In some embodiments, the front-end multilingual error message method can also be implemented through the following steps: Step S390: If the first error code matches the session expiration identifier, redirect to the front-end login page.

[0109] As described in step S27 above: Session expiration handling. In any level of degradation processing, if an error code indicating session expiration is detected, the degradation chain is interrupted and the user is directly redirected to the login page.

[0110] This application provides a unified session expiration handling logic to avoid repetitive implementation in multiple steps. While ensuring system security, it provides clear guidance for re-login. This protects user data security and improves user experience.

[0111] In some embodiments, a method for updating an error code mapping table is also provided, which can be implemented through the following steps: Step A: Store the error code mapping table in the cloud or the backend electronic device; Here, the error code mapping table is stored in the cloud (such as object storage) or on backend electronic devices (such as sensor devices) to decouple it from the frontend code.

[0112] It avoids hard-coding mapping tables, supports dynamic updates, and eliminates the need to redeploy front-end versions.

[0113] Step B: Update the error code mapping table in real time without updating the front-end version; Front-end proactive fetching: The front-end periodically (e.g., hourly) or when a specific event is triggered (e.g., page load) sends a request to the cloud / back-end to obtain the latest error code mapping table.

[0114] Backend proactive push: When the error code mapping table is updated, the backend notifies the frontend via WebSocket or message queue, and the frontend downloads the update after receiving the notification.

[0115] Step C: Obtain the updated error code mapping table from the cloud or the backend electronic device.

[0116] During implementation, the front end retrieves the updated mapping table and replaces the old version cached locally.

[0117] In this embodiment, the error code mapping table does not need to be hardcoded in the front-end code; it can be dynamically obtained from the back-end and cached, supporting real-time addition of error code mappings without updating the front-end version. Error message logic can be updated without redeploying the front-end version, adapting to rapid iteration needs. The error code mapping table decouples from the front-end code, supporting rapid iteration of error message logic without updating the front-end version, thus improving the system's flexibility and maintainability.

[0118] In some embodiments, "updating the error code mapping table in real time" in step B above can be achieved through the following steps: Step B1: Generate a list of unmapped error codes based on the first error code that does not match any error code identifier in the error code mapping table; During implementation, when the first error code cannot be matched with the existing error code mapping table, the service layer automatically records the error code and its associated degradation chain hierarchy information to form a structured list.

[0119] Step B2: Update the error code mapping table using the unmapped error code list.

[0120] In some embodiments, the list of unmapped error codes is sorted according to the following dimensions, with high-impact errors being prioritized: Frequency priority: High-frequency errors (such as those occurring more than 10 times per day) should be mapped first.

[0121] Business impact: Errors related to core interfaces (such as payment and login) should be handled first.

[0122] In this embodiment, error code usage statistics and coverage warnings are provided: by recording the level of each degradation chain hit at the service layer, the error codes entering the 2nd / 3rd / 4th level degradation are automatically counted, generating a "list of unmapped error codes" to assist developers in timely supplementing mapping relationships and gradually improving the coverage of the 1st level. This reduces the workload of manually maintaining the mapping table and achieves accurate supplementation through automatic statistics. It realizes the continuous evolution of the error code mapping table, ensuring the timeliness of error handling and continuously optimizing the mapping strategy through a data-driven approach, ultimately building a high-coverage, highly available multilingual error message system.

[0123] This application provides a front-end multilingual error display device. Please refer to [link / reference]. Figure 4 The device 400 includes: The first acquisition module 410 is used to acquire response messages sent by the backend electronic device through the Hypertext Transfer Protocol (HTTP) service layer set at the front end. The response message is the response of the backend electronic device to the HTTP request sent by the front end service layer. Extraction module 420 is used to extract the first error code from the response message when it is determined that the front-end business layer has not configured an error ignore flag; The second acquisition module 430 is used to acquire the error field in the first error code when it is determined that the first error code does not match any error code identifier in the error code mapping table. The third acquisition module 440 is used to acquire an HTTP response status code when the error field in the first error code is empty, wherein the HTTP response status code is a status code in response to the response message. The output module 450 is used to output a first prompt message that matches the language identifier of the front-end system when it is determined that the status code does not match the preset status code.

[0124] Figure 5 This is a schematic diagram of the structure of a computer device provided in an embodiment of this application. For example, as shown... Figure 5As shown, the computer device 500 includes: a memory 501, a processor 502, and a computer program 503 stored in the memory 501 and running on the processor 502, wherein when the processor 502 executes the computer program 503, the computer device can execute any of the aforementioned front-end multilingual error prompting methods.

[0125] Furthermore, this application also protects a control device, which may include a memory and a processor. The memory stores executable program code, and the processor is used to call and execute the executable program code to perform a front-end multilingual error prompting method provided in this application. This application can divide the control device into functional modules based on the above method examples. For example, each module can correspond to a specific function, or two or more functions can be integrated into a processing module. The integrated module can be implemented in hardware. It should be noted that the module division in this application is illustrative and only represents a logical functional division; other division methods may exist in actual implementation. It should also be noted that all relevant content of each step involved in the above method embodiments can be referenced to the functional description of the corresponding functional module, and will not be repeated here. It should be understood that the control device provided in this application is used to execute the above-mentioned front-end multilingual error prompting method, and therefore can achieve the same effect as the above-mentioned implementation method. When using integrated units, the control device may include a processing module and a storage module. When the control device is applied to a block device, the processing module can be used to control and manage the actions of the block device. The storage module can be used to support block devices in executing mutual program code, etc. The processing module can be a processor or controller, which can implement or execute various exemplary logic blocks, modules, and circuits described in conjunction with the disclosure of this application. The processor can also be a combination of functions that implement computing capabilities, such as a combination of one or more microprocessors, a combination of digital signal processing (DSP) and microprocessors, etc., and the storage module can be a memory.

[0126] Furthermore, the control device provided in the embodiments of this application may specifically be a chip, component, or module. The chip may include a connected processor and a memory. The memory stores instructions, and when the processor calls and executes the instructions, the chip can execute the front-end multilingual error display method provided in the above embodiments. The embodiments of this application also provide a computer-readable storage medium storing computer program code. When the computer program code is run on a computer, it causes the computer to execute the aforementioned method steps to implement the front-end multilingual error display method provided in the above embodiments.

[0127] This application also provides a computer program product. When the computer program product is run on a computer, it causes the computer to perform the aforementioned related steps to implement the front-end multilingual error prompting method provided in the above embodiments. The control device, computer-readable storage medium, computer program product, or chip provided in this application are all used to execute the corresponding methods provided above. Therefore, the beneficial effects they achieve can be referred to in the beneficial effects of the corresponding methods provided above, and will not be repeated here. Through the description of the above embodiments, those skilled in the art can understand that, for the sake of convenience and brevity, only the division of the above functional modules is used as an example. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the control device can be divided into different functional modules to complete all or part of the functions described above. In the embodiments provided in this application, it should be understood that the disclosed control device and method can be implemented in other ways. For example, the control device embodiments described above are merely illustrative. For example, the division of modules or units is merely a logical functional division. In actual implementation, there may be other division methods. For example, multiple units or components can be combined or integrated into another control device, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be an indirect coupling or communication connection through some interface, control device or unit, and can be electrical, mechanical or other forms.

[0128] It should be noted that the order of the embodiments described above is merely for descriptive purposes and does not represent the superiority or inferiority of the embodiments. The processes depicted in the accompanying drawings do not necessarily require a specific or sequential order to achieve the desired results. In some embodiments, multiple task processing and parallel processing are possible or may be advantageous. The various embodiments in this specification are described in a progressive manner, and the same or similar parts between the various embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. The above content is only a specific implementation of this application, but the protection scope of this application is not limited thereto. Any changes or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the protection scope of this application.

Claims

1. A method for displaying multilingual error messages on a front-end, characterized in that, The method includes: The Hypertext Transfer Protocol (HTTP) service layer set up at the front end obtains response messages sent by the back-end electronic device. The response message is the response of the back-end electronic device to the HTTP request sent by the front-end business layer. If it is determined that the front-end business layer has not configured an error ignore flag, the first error code is extracted from the response message; If it is determined that the first error code does not match any error code identifier in the error code mapping table, the error field in the first error code is obtained; If the error field in the first error code is determined to be empty, the HTTP response status code is obtained, wherein the HTTP response status code is a status code in response to the response message; If it is determined that the status code does not match the preset status code, a first prompt message matching the front-end system language identifier is output.

2. The method as described in claim 1, characterized in that, The method further includes: After obtaining the response message sent by the backend electronic device, if it is determined that the error ignore flag of the frontend business layer is configured to a first preset value, the first preset value is used to instruct the HTTP service layer not to uniformly process the error codes in the response message; The response message is returned to the front-end business layer; The front-end business layer obtains the second error code in the response message and executes the second output operation corresponding to the second error code.

3. The method as described in claim 1, characterized in that, The method further includes: After obtaining the response message sent by the backend electronic device, if it is determined that the error ignore flag configuration of the frontend business layer includes a string array, the string array is used to match the error code in the response message; It was determined that a third error code in the response message matched the string set in the string array; Return the third error code to the front-end business layer; The front-end business layer executes the third output operation corresponding to the third error code based on the third error code.

4. The method as described in claim 1, characterized in that, The method further includes: If it is determined that the first error code matches any error code identifier in the error code mapping table, a second prompt message corresponding to the first error code is output, wherein the second prompt message matches the front-end system language identifier.

5. The method as described in claim 4, characterized in that, When it is determined that the first error code matches any error code identifier in the error code mapping table, a second prompt message corresponding to the first error code is output, including: The first error code is determined to match an error code template with preset parameters set in the error code mapping table; Fill the error code template with the first parameter that matches the preset parameter in the error code template; The error code template with completed parameter filling is output as the second prompt message.

6. The method as described in claim 1, characterized in that, The method further includes: If the error field in the first error code is determined to be a non-empty error text, the error text is output as a third prompt message.

7. The method as described in claim 1, characterized in that, The method further includes: If the status code matches a preset status code, a fourth prompt message based on the preset status code is output.

8. The method according to any one of claims 1 to 7, characterized in that, The method further includes: If the first error code matches the session expiration identifier, the user is redirected to the front-end login page.

9. The method according to any one of claims 1 to 7, characterized in that, The method further includes: The error code mapping table is stored in the cloud or in the backend electronic device; The error code mapping table is updated in real time without updating the front-end version; Obtain the updated error code mapping table from the cloud or the backend electronic device.

10. The method as described in claim 9, characterized in that, The real-time updating of the error code mapping table includes: Based on the first error code that does not match any error code identifier in the error code mapping table, generate a list of unmapped error codes; Update the error code mapping table using the unmapped error code list.

Images