Localization is automatically displayed to users based on the locale of the person logging into the Portal. Localization of number formats and dates provides a consistent experience based on what the logged in user is accustomed to in their native locale.

While locale is not the same as language, it can be related to language (for example, you can “localize” English to UK English). From a Portal perspective, a user may access a Portal in a language that is different from their locale. In this case, the user’s experience will be presented in their native locale, but the language will be displayed based on what is configured by an administrator.

Simply put, “what is displayed” (the language) is controlled by an admin, while “how it’s displayed” (locale) is automatically adjusted for the user.

When using the default language (English en-us), no further localization is required.

If another language is desired, or a localized version of English is desired, the following areas must be updated:

Language packs are not provided, and the assumption here is that a single language will be displayed throughout the Portal.

When it comes to menus and reports, menu items and report titles require manual updates by an admin before it can be configured for a specific language. By default, all menus and reports are “localized” to US English (en-us) (that is, the language of display is US English) and if language strings for another locale are desired (for example, UK English), then this will replace the previous language strings.

Menus currently only support a single language, however this language may be translated or localized as described below.

To localize a menu:

  1. Go to: InterConnect Manager AddOn > Manage Menu.

  2. Select the desired application and menu.

  3. For each Menu Entry, ensure the entry’s Name field is translated. This is the link name displayed to the end customer.

  4. For Menu Entries that are Grids, Pivots or Charts, open the report Link and edit the Query columns associated with that link. Edit the Query using the standard SAP Business One query editor. Always back up queries to a safe location before making edits.

  5. Recycle the B1WebAPI’s application pool. This will clear the cached language default for all Portals. See Recycling Application Pools for a walkthrough of this step.

  6. Recycle the Portal’s application pool. This will re-load the language default from B1WebAPI. See Recycling Application Pools for a walkthrough of this step.

Report Localization

Reports may be localized in a Portal by configuring query column aliases that display to web users. Notably, some queries contain columns that are not displayed to the web user, and these query aliases must remain intact. A list of query requirements when applying localization are provided below.

For standard queries, edits may be made using the query editor in SAP Business One. For queries that call stored procedures, edits must be applied within the stored procedure.

When localizing a report that contains a query link, the query itself is not the source of the column name. These query links may be re-aliased as described in the Query Link Localization section below.

Localization Requirements for Queries

Query Description Requirements
B1WebAPI_SU / _OMAN_GET_OPPORTUNITIES_FOR_BOARD This query is used on the Opportunities Board and executes a stored procedure ZED_OMAN_GET_OPPORTUNITIES_FOR_BOARD. This stored procedure must be updated. All fields must remain aliased without changes. Field names are not displayed to end users.

However, Opportunity Stage names that are displayed are based on the default SAP Business One settings. If Opportunity Stage names must be localized, the value of the “Name” field may be change in the stored procedure ZED_OMAN_GET_OPPORTUNITIES_FOR_BOARD. This type of edit requires advanced skills in SQL/Hana query editing.
B1WebAPI_SU / Opportunity Analysis This is a standard Pivot report. No special requirements.
B1WebAPI_SU / Opportunity Analysis - All This is a standard Pivot report. No special requirements.
B1WebAPI_SU / _OMAN_MYCUSTS This is a standard Grid report. Customer alias is found in the Query Link UDT ZEDS_QUERYLINK. See Query Link localization below.
B1WebAPI_QueryPortal / My Sales Orders This is a standard Grid report. Customer alias and Ref # aliases are found in the Query Link UDT ZEDS_QUERYLINK. See Query Link localization below.

Other fields have no special requirements.
B1WebAPI_QueryPortal / My Sales Quotes This is a standard Grid report. Customer alias and Quote # aliases are found in the Query Link UDT ZEDS_QUERYLINK. See Query Link localization below.

Other fields have no special requirements.
B1WebAPI_SU / _OMAN_GET_MY_OPEN_ACTIVITIES This is a standard Grid report. Task Name alias is found in the Query Link UDT ZEDS_QUERYLINK. See Query Link localization below.
B1WebAPI_SU / _OMAN_GET_MY_CLOSED_ACTIVITIES This is a standard Grid report. Task Name alias is found in the Query Link UDT ZEDS_QUERYLINK. See Query Link localization below.
B1WebAPI_SU / _OMAN_INVREPORT This is a standard Grid report. No special requirements.
B1WebAPI_SU / Last Orders This is a standard Pivot report. No special requirements.
B1WebAPI_SU / _OMAN_SALESANALYSIS This is a standard Chart report. No special requirements.
B1WebAPI_Expense / RP_ExpRequests This is a standard Grid report. Details alias is found in the Query Link UDT ZEDS_QUERYLINK. See Query Link localization below.
B1WebAPI_Expense / RP_ExpRequestDetails This is a standard Grid report. Details alias is found in the Query Link UDT ZEDS_QUERYLINK. See Query Link localization below.
B1WebAPI_Expense / RP_ExpClaims This is a standard Grid report. Details alias is found in the Query Link UDT ZEDS_QUERYLINK. See Query Link localization below.
B1WebAPI_Expense / RP_ExpClaimDetails This is a standard Grid report. Details alias is found in the Query Link UDT ZEDS_QUERYLINK. See Query Link localization below.
B1WebAPI_Expense / RP_MyRequests This is a standard Grid report. Details alias is found in the Query Link UDT ZEDS_QUERYLINK. See Query Link localization below.
B1WebAPI_Expense / RP_MyApprovalHistory This is a standard Grid report. Details alias is found in the Query Link UDT ZEDS_QUERYLINK. See Query Link localization below.
B1WebAPI_Expense / RP_ApprRequestLinesNotClaimed This is a standard Grid report. Details alias is found in the Query Link UDT ZEDS_QUERYLINK. See Query Link localization below.
B1WebAPI_Expense / RP_MyClaims This is a standard Grid report. Details alias is found in the Query Link UDT ZEDS_QUERYLINK. See Query Link localization below.
B1WebAPI_Expense / RP_ExpenseAnalysis This is a standard Pivot report. No special requirements.

When localizing query reports, if the query has a corresponding Query Link (that is, if a web drill-down link has been set up for the report), then that query requires localization of the label associated with its drill-down link. This is done within the ZEDS_QUERYLINK UDT (User-Defined Table).

  1. First, open the ZEDS_QUERYLINK UDT under Tools > User-Defined Windows > ZEDS_QUERYLINK - Portal Query Doc Link.

  2. Next, scroll right to the Grid Column Title field. This is the text that will be displayed to the end user. Change this to the desired value.

    Edit the Grid Column Title field (1) to change what is displayed to end users.
    Edit the Grid Column Title field (1) to change what is displayed to end users.

  3. Update the UDT.

  4. Recycle the B1WebAPI’s application pool when all query links are edited. This will clear the cached query links for all Portals. See Recycling Application Pools for a walkthrough of this step.

  5. Recycle the Portal’s application pool. This will re-load changed query links from B1WebAPI. See Recycling Application Pools for a walkthrough of this step.

Application String Localization

Application Strings may be localized on the web server by updating the Values found in the Portal website’s App_GlobalResources/AppStrings.resx file.

Before making changes to this file:

  • Always back up the AppStrings file before making edits.
  • Saving the AppStrings file will restart the website, disrupting web users. Best practice is to update a test site first, confirm the details, then load the changes to production at a time when few users are logged in.

  • Application String files are well-formed XML. As a result, exercise caution when making edits so that the XML remains well-formed.

    Also, when editing Application Strings for a Portal, ensure that the Value field does not contain any prohibited XML characters. Instead, use XML-safe versions of special characters. For a helpful guide, see: Stack Overflow - What characters do I need to escape in xml documents and the more technical deep-dive: W3C - XML.

  • Included in the Application Strings file are breadcrumb labels, which all begin with the word “Breadcrumb”, for example, BreadcrumbHome. Replace the value associated with each breadcrumb link to update breadcrumbs displayed to web users.

How to update Application Strings

  1. Open the Application Strings file. This may be done using an advanced editor such as Visual Studio, or a basic text editor.

  2. Find and update the desired label.

    In Visual Studio, the “Name” field contains the identifier for the label and should not be changed, while Value contains its content. Values will display to the end user and can be updated. Comments are sometimes provided to clarify details related to this web label and typically don’t need to be updated, but can be updated for internal reference purposes.

    In a text editor, <data name="BreadcrumbHome" xml:space="preserve"> identifies a label (here the label for “BreadcrumbHome”) and should not be changed, while the contents of <value> may be edited to change what’s displayed on the web.