On 12.08.2020 11:46, Milos Sramek wrote:
> Hi,
> I've checked the code. These strings are defined in file
> ./sw/inc/inspectorproperties.hrc:
>
> #define NC_(Context, String) reinterpret_cast(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.
>
> On 8/10/20 11:56 AM, Caolán McNamara wrote:
>> 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.
--
Best regards,
Mike Kaganski
--
To unsubscribe e-mail to: l10n+unsubscr...@global.libreoffice.org
Problems? https://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: https://wiki.documentfoundation.org/Netiquette
List archive: https://listarchives.libreoffice.org/global/l10n/
Privacy Policy: https://www.documentfoundation.org/privacy
