OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xliff-users message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: Guidance for creating SLRÂprofile


Hi Jan,

 

It looks mostly reasonable to me. You are not using the sizeRestriction attribute of the module, which I think is a mistake. Your proprietary checker will likely work anyway, but you lose some interoperability with tools that do not understand your profile. I would probably also move the custom elements in the <profiles> element under a single child. If you have both custom general and storage profiles it will probably look cleaner if their settings are not mixed directly under <profiles>

 

If you use sizeRestriction it conveys at a minimum the fact that there is a restriction in place on a particular span of content. That would allow other tools to highlight that fact or to trigger warnings or cause them to skip processing since they can not enforce the restriction. It would also allow automatic flagging during batch translation or machine translation that a span with a restriction changed and need to be checked by some stand alone checker.

 

By using only sizeInfo{Ref} you do not indicate to implementers of the slr module that there is a restriction in place. Just that there is sizing information available that would influence the size of the span.

 

It would also make the custom module follow the spirit of the standard.

5.7.5.7 sizeRestriction: It MUST represent the restriction to apply to the indicated sub part of the document.

5.7.5.9 sizeInfo : It MUST represent information related to how the element it is attached to contributes to the size of the text or entity in which it occurs or represents.

 

If you should keep Height and Width in the <data> part depends on if the size of the span is fixed regardless of how big the contained text is, in which case you should keep it. Or if the size would shrink and grow with the content in which case it should most likely be removed.

 

With those changes it would look something like this:

 

        <slr:profiles generalProfile="my-org:foo-ui">

            <my-org:foo-ui-settings>

               <my-org:text-align>center</my-org:text-align>

               <my-org:font-family>A Font Face</my-org:font-family>

               <my-org:font-size>13px</my-org:font-size>

               <my-org:font-color>#ffffff</my-org:font-color>

               <my-org:font-weight>normal</my-org:font-weight>

               <my-org:font-style>normal</my-org:font-style>

           </my-org:foo-ui-settings>

        </slr:profiles>

        <unit id="1">

            <slr:data profile="">

                <my-org:profile xml:id="slr1">

                    <my-org:font-size>8px</my-org:font-size>

                    <my-org:top>11px</my-org:top>

                    <my-org:left>7px</my-org:left>

                    <my-org:width>47px</my-org:width> <!âRemove if not static regardless of content -->

                    <my-org:height>19px</my-org:height> <!âRemove if not static regardless of content -->

                </my-org:profile>

            </slr:data>

            <segment>

                <source><sc canDelete="no" canOverlap="no" id="1" slr:sizeRestriction=â47px 19pxâ slr:sizeInfoRef="slr1" />Button<ec

                        canDelete="no" canOverlap="no" startRef="1" /></source>

            </segment>

        </unit>

 

The only really important change is to use the sizeRestriction attribute so any implementer of the slr module would at least be able to see that there is âsomeâ restriction on the restricted spans even if it can not check it.

 

Regards,

Fredrik Estreen

 

From: Jan Husarcik [mailto:JHusarcik@moravia.com]
Sent: den 16 juli 2018 17:49
To: Estreen, Fredrik <Fredrik.Estreen@lionbridge.com>; xliff-users@lists.oasis-open.org
Subject: RE: Guidance for creating SLR profile
Sensitivity: Private

 

Hi Fredrik,

 

thanks a lot for the quick and extensive response. You are right, Iâm definitely aiming for a proprietary usage.

 

Based on your feedback Iâve came up with something like this (havenât chosen the prefix/name yet):

        <slr:profiles generalProfile="my-org:foo-ui">

            <my-org:text-align>center</my-org:text-align>

            <my-org:font-family>A Font Face</my-org:font-family>

            <my-org:font-size>13px</my-org:font-size>

            <my-org:font-color>#ffffff</my-org:font-color>

            <my-org:font-weight>normal</my-org:font-weight>

            <my-org:font-style>normal</my-org:font-style>

        </slr:profiles>

        <unit id="1">

            <slr:data profile="">

                <my-org:profile xml:id="slr1">

                    <my-org:font-size>8px</my-org:font-size>

                    <my-org:top>11px</my-org:top>

                    <my-org:left>7px</my-org:left>

                    <my-org:width>47px</my-org:width>

                    <my-org:height>19px</my-org:height>

                </my-org:profile>

            </slr:data>

            <segment>

                <source><sc canDelete="no" canOverlap="no" id="1" slr:sizeInfoRef="slr1" />Button<ec

                        canDelete="no" canOverlap="no" startRef="1" /></source>

            </segment>

        </unit>

 

Iâve put defaultâs in the <slr:profiles>, though Iâm overwriting <my-org:font-size> later. At the moment, Iâm considering just single level restrictions, though I could put slr:sizeInfoRef on the whole unit/group as needed (with appropriately placed <slr:data>).

 

Coordinates/dimensions and overrides are stored in one of <slr:data>/<my-org:profile> children, referenced from <sc>/<ec> via slr:sizeInfoRef. Iâve opted for codes, as they can be protected using Editing Hints (did not want to bother with markers that can be removed in target). Iâm using xml:id for identifying the <slr:data> child. Still not sure about canOverlap though.

 

Using slr:sizeInfoRef due to size of the data and my overall preference.

 

What do you think?

 

Regards,

JÃn

 

From: Estreen, Fredrik [mailto:Fredrik.Estreen@lionbridge.com]
Sent: Thursday, July 12, 2018 00:12
To: Jan Husarcik <JHusarcik@moravia.com>; xliff-users@lists.oasis-open.org
Subject: Re: Guidance for creating SLR profile
Sensitivity: Private

 

Hi Jan,

 

I'm not active with XLIFF standardization at this time but I try to keep an eye on it and worked a lot on this module in the past. So I'll try to provide some guidance. First something you probably already know, the type of profile you want to design would be very hard to design for general use, but could more easily be designed for proprietary or case specific usage.

 

You will want to design a "general" profile for this use case, the module supports both a general size profile and a storage size profile in parallel.

 

Step one is to pick a prefix that could make sense for a collection of custom profiles for a case or your organization. And a name for the actual profile. Like "my-org:foo-ui"

 

Depending on how configurable you want the profile to be you may or may not need to define a way to express the base parameters in the slr modules <profiles> element using elements from a namespace outside XLIFF, likely one defined by you. For rendering things like DPI, layout engine and engine options, default font parameters etc could make sense. You will want to place any parameters that apply to the file/group/unit level and affect the overall profile behavior here.

 

Next you will want to define how to express the size restriction on some portion of content. If you have a single line it could be as simple as just the number of pixels. It sounds like you may want a box and then for a 100x50 box something like "100x50" or "100 50" would be a straight forward notation. If you plan to support different units in the future "100px 50px" or similar would make more sense. You would use values of the form you define here in the "sizeRestriction" attribute from the slr module to restrict the size of a portion of content. It is supported on files, groups, units, marker (mrk/sm+em) spans and spanning inline codes (pc/sc+ec). So you have the expressiveness it sounds like you need by using this attribute. When restricting the size of multiple spans in a single unit you will need to do that using marker or inline codes. Unless you already have inline codes that fully contain your spans I would recommend using the inline marker elements. Both ways are independent of segmentation. Don't try to tie restrictions to segments as that would break the expectations that tools can re-segment units. You should probably make a decision if you want to be able to support hierarchical or just single level restrictions. Like a max combined size for a box/frame/dialog and inside it individual constraints on spans of content. If you think about it from the beginning you can likely start out with single level and have a path to do more complex later.

 

Finally you will want to define how you express changes that affect rendering like a change in font, font-size, font-weight, etc. This can be done in two ways either fully inline using the "sizeInfo" attribute or as referenced information using the "sizeInfoRef" attribute which would point to a <data> element in the same <unit> or an ancestor <group> or <file> element. Which method to use mostly depends on how big the information is and what style you prefer. You can even mix the two but I would personally stick to one or the other. This information can be placed on files/groups/units and all the inline original code elements (pc,sc,ec,ph). This decouples the effect of the native markup from the original markup itself. Which is useful if you want to be able to use the same core checker on different types of markup or if the markup changes. These attributes can also be used to express a fixed or maximum size of the element the attribute is present on. Like a <ph> that will be replaced by a variable of up to N characters or an icon that is XxY pixels big.

 

Hope this helps a bit and I'm happy to try answering other questions in this area.

 

Best regards,

Fredrik Estreen


From: Jan Husarcik <JHusarcik@moravia.com>
Sent: Wednesday, July 11, 2018 11:00:54 PM
To: xliff-users@lists.oasis-open.org
Subject: [xliff-users] Guidance for creating SLR profile

 

Hi,

Iâm looking for a guidance for creating a SLR profile with following purpose:

Validate that target text with defined

-          font face

-          font size (px)

-          decorations (bold, italic, small-caps, â)

would fit into text box of defined dimensions (px). Itâs likely that there would be multiple spans with different limitations within single <unit>.

Would you kindly advise?

Topicâs briefly mentioned in 2.1 spec (5.7.7 Third party profilesâ http://docs.oasis-open.org/xliff/xliff-core/v2.1/os/xliff-core-v2.1-os.html#d0e16864), but without further details.

Regards,

Jan

 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]