626363 - [l10n] truncated strings in Security Devices window

Status: REOPENED

(Firefox :: Settings UI, defect)

Description

[Anas Husseini [:linostar]]

In security/manager/chrome/pipnss/pipnss.properties, several strings have a l10n note that indicate they are limited to 32 or 64 bytes. For some locales, their alphabetic letters require at least 2 bytes per character in UTF-8 encoding. The result is that translated strings longer than 16 characters are truncated, and it almost impossible to shorten some of those strings to 16 characters or less.

Proposed solution: make the limitation 32 characters instead of 32 bytes (the space is enough for 32 characters), or add a variable (string) in pipnss.properties that enables the localizer to change the string length in bytes (or alternatively the line width).

How to reproduce:
Go to the Preferences window > Advanced > Encryption > Security Devices.

Comment 1

[Anas Husseini [:linostar]]

By the way, all rtl locales are affected. Some other locales may be too.

Comment 2

[Axel Hecht [:Pike]]

Kai added those comments in bug 90956, and I can't see why the limitations are there. Kai?

Comment 3

[(no longer active)]

This doesn't have anything to do with right-to-left support.

Comment 4

[Kai Engert (:KaiE:)]

Short answer: No, we cannot increase the sizes, because we are using a standard interface that has a size limitation.

Long answer:

Mozilla uses NSS as its crypto toolkit.
There is a standard called PKCS#11 that describes "devices" that perform crypto operations.
"Devices" can be either "hardware" or "software".
NSS has followed the strategy to use the PKCS#11 interfaces to allow to work with third party crypto modules, that can be used as plugins into NSS.
As a matter of simplification, NSS uses the same interface for some internal modules, too.
These modules include the storage module for your private keys (software security device) and the list of trusted root certificates (builtin module).

The strings you have referenced are the identifiers used for our internal PKCS#11 modules, and they must follow the size restrictions that are described by the PKCS 11 interface documentation.

I don't have good ideas what to recommend, other than "try to be creative with a short name" or "just keep the original english name".

Unfortunately this must be resolved as WONTFIX.

Well. In theory someone could implement a solution that always keeps the short strings in the device emulation, and changes all our displaying code to dynamically detect whenever we work with a builtin module, and dynamically replace the strings with localized strings.

Comment 5

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

> Well. In theory someone could implement a solution that
> always keeps the short strings in the device emulation,
> and changes all our displaying code to dynamically
> detect whenever we work with a builtin module, and
> dynamically replace the strings with localized strings.

I think this is the right solution. But, it is a low priority.