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: https://imgur.com/xu2Wvh2
Milos


On 8/12/20 11:50 AM, Mike Kaganski wrote:
> 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<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.
>
>> 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: sramek.mi...@gmail.com


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

Reply via email to