Date: prev next · Thread: first prev next last
2020 Archives by date, by thread · List index

Thank you Mike,
its clear now, I will try to translate the strings in a similar cryptic way.

For the others: The inspector does not display correctly yet (in the dev
version), this is how it should look like:

On 8/12/20 11:50 AM, Mike Kaganski wrote:
On 12.08.2020 11:46, Milos Sramek wrote:
I've checked the code. These strings are defined in file

#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                                  
#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?

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
( 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.

email & jabber:

To unsubscribe e-mail to:
Posting guidelines + more:
List archive:
Privacy Policy:


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.