Hi,
I've checked the code. These strings are defined in file
./sw/inc/inspectorproperties.hrc:
#define NC_(Context, String) reinterpret_cast<char const *>(Context
"\004" u8##String)
/*--------------------------------------------------------------------
Description: API names for Paragraph, Character
and Text cursor properties
--------------------------------------------------------------------*/
// Format names
#define RID_BORDER_DISTANCE
NC_("RID_ATTRIBUTE_NAMES_MAP", "Border Distance")
#define RID_BOTTOM_BORDER
NC_("RID_ATTRIBUTE_NAMES_MAP", "Bottom Border")
#define RID_BOTTOM_BORDER_DISTANCE
NC_("RID_ATTRIBUTE_NAMES_MAP", "Bottom Border Distance")
(217 of them)
Is it sure that a user can see these strings somewhere in a translated form?
Definitely.
If yes, then we need to know structure of these strings (they do not
seem to be sentences) and how are they presented, since many of them
have 'cryptic" form like
Fill Bitmap Rectangle Point
Char Interoperability Grab Bag
Char Weight Complex
Some background.
These strings are related to the Styles Inspector - a GSoC project,
being implemented by Shivam Kumar Singh
(https://bugs.documentfoundation.org/show_bug.cgi?id=134554). The
inspector is already available in Experimental mode (see comment 2 in
the meta issue).
The Inspector presents a detailed low-level view of properties applied
at the cursor. As such, it shows the multitude of attributes applied to
text (or other object in the future); most these attributes have their
names in multiple dialogs throughout the UI, but this is the first time
when all of them need to be named in a single place. And translation in
dialogs can not be used directly, e.g. because the translation there in
dialogs may use context absent in the Inspector.
One possible improvement could be to provide a hint somehow near the IDs
in inspectorproperties.hrc, where known/possible, to the related strings
in the dialogs/other UI parts, to help translators understand what this
item is about. But that's a separate task/TODO: the current work on
Inspector does not consider dialogs; the Inspector is created based on
the properties available using UNO API, and thus Shivam does not know
where the items are located in existing UI. (This is to clarify that
there's no information already used by developers, potentially useful to
translation, that was somehow lost during development.)
The names that Shivam has put there are possibly somewhat "cryptic"
exactly because of the mentioned specifics: the names are mostly the API
names, which were split by CamelCase to produce strings like "Char
Weight Complex", intended to be used in context of table like
Char Interoperability Grab Bag "some string"
Char Weight Complex 10
So the mentioned TODO would also allow to gradually find the existing
names of the attributes, and make them consistent in the Inspector.
There is already a member in SfxPoolItem "GetPresentation" which is
used in the "organizer" tab of some dialogs to give a human-readable
representation of an SfxPoolItem, I wonder (without looking into it) if
that is anyway useful in this circumstance.
Thanks Caolán!
Note that SfxPoolItem::GetPresentation provides a property *value*, not
its name. See tdf#134561, where I propose using this function for the
purpose of getting "natural" attribute values.
![[TEST] Document Foundation Community](https://communitytest.documentfoundation.org/images/discourse-logo-sketch.png){kind=logo}