nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

International FormsPublisher Interfaces. Anyone ever done this?

Tim__D

Has anyone successfully created a FormsPublisher interface that could be "localized" for another langauge simply by configuration or branch location.

I am exploring two options one using FormAPI and one using <inline />

I would be interested in any feedback you may have.

Find more posts tagged with

Comments

Tim__D

Has anyone successfully created a FormsPublisher interface that could be "localized" for another langauge simply by configuration or branch location.

I am exploring two options one using FormAPI and one using <inline />

I would be interested in any feedback you may have.

I would really appreciate some input on this from someone. Interwoven?

It is curious that the entire user interface of TeamSite changes language based on a users computer language code, however workflows and forms developed in the ways outlined by Interwoven provide no method of localization. I must me missing something here...

ISCBorisB

I would really appreciate some input on this from someone. Interwoven?

It is curious that the entire user interface of TeamSite changes language based on a users computer language code, however workflows and forms developed in the ways outlined by Interwoven provide no method of localization. I must me missing something here...

You'd have to be way more specific to get any meaningful help. Please note that OOTB Forms Publisher interface
adheres to TS Server locale. The locale is normally set during installation. TS Server can not be run in multiple
locales concurrently. So, the formal answer to your request is perhaps "No, it can not be done", not 100% anyway.

That said, you yourself can code for some locale mix where Developer controlled DCT assets (Labels, Descriptions, CGI API
and whatnot) are rendered in the locale other than TS Server depending on your own recognition criteria. Once again, that
may create Language mix within same DC Form. If that's acceptable, describe at least some details

Tim__D

You'd have to be way more specific to get any meaningful help. Please note that OOTB Forms Publisher interface
adheres to TS Server locale. The locale is normally set during installation. TS Server can not be run in multiple
locales concurrently. So, the formal answer to your request is perhaps "No, it can not be done", not 100% anyway.

That said, you yourself can code for some locale mix where Developer controlled DCT assets (Labels, Descriptions, CGI API
and whatnot) are rendered in the locale other than TS Server depending on your own recognition criteria. Once again, that
may create Language mix within same DC Form. If that's acceptable, describe at least some details

Sorry for the lack of detail. I should know better Smiley Wink

. Basically I would like to develope a DCT which can be configured for a variety of languages based on branch location or other configuration. This DCT would allow me to easily configure the DCT with no changes to the actual DCT for a local language and also allow me to easily swap the labels to English for a US English only support team.

I'm currently in discovery on a solution. I have explored using master access ACL to enable a langauage toggle on the DCT. I then use FormAPI to change the labels in the DCT to the local language. There are a bunch of issues with this solution.

1). FormAPI has issues when adding replicants and changing the lables. I cant get it working.

2). Currently I'm storing the labels in an associative array which consists of the english string as the key [0] and a language object [1] which acts as a hash of language codes and translated values.

The solution works well enough that it helps with my problem but I think I may need a more heavy handed approach.

The other idea was to use [inlines /]. I would basically create a "shell" dct which would load another xml document representing the real DCT. I would parse and translate the real DCT and return the substitution xml using the [inline/]. Great idea! However, inlines are only parsed once as I understand it and I dont like the idea of not being able to use [inlines/] simply because I set up a DCT for translation.

I'm pretty much stuck at this point and have moved on to other projects. I am still pursuing this for a project in the very near future.

By the way, our TeamSite server is set up for English but content center standard completly changes to Japanese when you chnage your computers language code. Thats is, except for DCT's and Workflows hence the reason for this post and possibly feature request.

ISCBorisB

If I were you, I would do neither <inline> nor FormAPI. Instead, I would code some sort of "DCT Preprocessor".

This code one and the only purpose in life would be to take a DCT and inject desired collection of internal XML
entities into it, see sample below. This approach constraints are:

1. Locale-dependent DCT 's string literals should all be coded as references
2. There is a repository somewhere to supply Label/Value pairs to build XML Entities ( Flat Files, XMLs, dedicated DCRs, DB, _your_own_repository_format_here_ )

You may even expose that *Preprocessor* to DCT developers via Custom Menu CGI Item, to be run against *checked* DCT with Locales drop-down, etc...[html]

&itm_label_language;

...

[/html]

Tim__D

If I were you, I would do neither <inline> nor FormAPI. Instead, I would code some sort of "DCT Preprocessor".

This code one and the only purpose in life would be to take a DCT and inject desired collection of internal XML
entities into it, see sample below. This approach constraints are:

1. Locale-dependent DCT 's string literals should all be coded as references
2. There is a repository somewhere to supply Label/Value pairs to build XML Entities ( Flat Files, XMLs, dedicated DCRs, DB, _your_own_repository_format_here_ )

You may even expose that *Preprocessor* to DCT developers via Custom Menu CGI Item, to be run against *checked* DCT with Locales drop-down, etc...[html]

&itm_label_langauge;

...

[/html]

Very intereting...some questions.....

1). Would the preprocessor operate and modify a DCT such that it needed to be versioned (checked back into TeamSite). I'm really looking for something that can take an universal DCT and make it local before it loads. On the fly so to speak.

2). Would an [inline/] be capable of injecting the entities? I think it could?

ISCBorisB

Very intereting...some questions.....

1). Would the preprocessor operate and modify a DCT such that it needed to be versioned (checked back into TeamSite). I'm really looking for something that can take an universal DCT and make it local before it loads. On the fly so to speak.

2). Would an [inline/] be capable of injecting the entities? I think it could?

1. You'd have to work it out. Depending on how you architect the whole thing, the DCT XML shared source can be set
(for example) in some dedicated Branch, a peer perhaps to your *DCT Target* Branch. That will give you proper DCT
source versioning and so on. Alternatively you can modify DCTs "In Place" or maintain them outside of iw-store
altogether.

2. Don't think so, wrong logistics. Entity is a directive to the parser and parser should well, parse DCT before
any TS Functionality takes place. That said, I never tried. After all, TS parses at least twice, it may work. Try it and let us all know.

Adam Stoller

If I were you, I would do neither <inline> nor FormAPI. [...]

Out of curiosity - why would you not use an inline?
I can think of a couple of reasons:

The first shouldn't be too bad if the code is reasonably efficient, the second could be gotten around by using multiple inlines for sections of the DCT - but that would then play into the cons of the first issue.Did you have some other reason(s) in mind?

ISCBorisB

[QUOTE=ghoti]Out of curiosity - why would you not use an inline?
I can think of a couple of reasons:

Good reasons both. Two more:- Problems with inline's nesting ( there are few ways to deal with it but that's the topic for different thread )Without extra coding outermost Locale Inline will block all "inner" DCT's inlines.- 90% of *Locale-dependent* coding are numerous substitutions of small non-structured string Literals. That doesnot map well to DCT inline schema. It seems a bit silly to make potentially dozens calls to get single translatedword from each ( and have to encapsulate it into XML too!)Once again, with some naming/substitution conventions there are perhaps ways to deal with it like do "bulk number" of substitutions in one shot, etc. All of it is a serious violation of KISS principle though.

Tim__D

1. You'd have to work it out. Depending on how you architect the whole thing, the DCT XML shared source can be set
(for example) in some dedicated Branch, a peer perhaps to your *DCT Target* Branch. That will give you proper DCT
source versioning and so on. Alternatively you can modify DCTs "In Place" or maintain them outside of iw-store
altogether.

2. Don't think so, wrong logistics. Entity is a directive to the parser and parser should well, parse DCT before
any TS Functionality takes place. That said, I never tried. After all, TS parses at least twice, it may work. Try it and let us all know.

Ok. I'll have to research this solution a bit more. Internal / External entities etc...

The one issue I do have is that entities work well for general repeatable things. Header,Footer,Name etc..

I could be dealing with strings unique to a variety of DCT's accross the enterprise. I suppose after a while standards will emerge (and already have) Link Text, Link URL etc.. over time I guess I would have in affect a library of entities that I could use to define a standard. Still the idea of having to create an entity for every label, option and description is a bit daunting Smiley Wink

ISCBorisB

Still the idea of having to create an entity for every label, option and description is a but daunting

Perhaps you misunderstood. In the simplest case you'll create one Property File per Locale. That File will contain name/value pairs
for the desired Language, that's it. It is easy to maintain, edit, translate (only values!) and so on. That's what I've called "repository" in
my previous Post. The *preprocessor* then may generate on the fly the whole collection of Entries for a particular DCT, either the whole
list is used within it or not.

Daunting as it may be, the practice to use locale-neutral Labels within code and render locale-dependent Label Values
upon request (run-time) is the standard mechanism to deliver multi-lingual Applications. Label/Value mapping mechanisms may
differ dramatically depending on your Platform, main principle is the same though.

Take for example Team Site. If you look at their JSPs ( not "View Source" - raw JSPs! ) you will not find any familiar
label whatever - none. Instead, you'll see tons of something like the following:

<i18n:getText key="login.login.button.label" bundle="com.interwoven.ui.teamsite.common"/>.

What do you think those "bundles" are? I can guarantee they are Java Objects (of some subclass) of ResourceBundle Class.
That is nothing more than a collection of Key/Value pairs, in memory or mapped to the property File (plus few methods to manipulate them)

Tim__D

[QUOTE=ISCBorisB]Perhaps you misunderstood. In the simplest case you'll create one Property File per Locale. That File will contain name/value pairs
for the desired Language, that's it. It is easy to maintain, edit, translate (only values!) and so on. That's what I've called "repository" in
my previous Post. The *preprocessor* then may generate on the fly the whole collection of Entries for a particular DCT, either the whole
list is used within it or not.
QUOTE]

Yes. I do understand the principal. I only struggle at what level I define a properties file. I do want the system scalable and flexible. Ideally I could define it at the DCT, Category, Branch or Site levels. I'll have to think that through. I've been doing some research and have discovered some interesting things.

1). Its posible to include an external entity in a DCT to render the labels. This is done by defining an entity to a DTD and then including the entity.

This means that as long as (as you said) all labels are indeed entities, I can achieve what I want using simple xml. In addition, what I have found is that these dont need to be internal entities and can be externalized.

What do you think for this approach? At the end of the day there is still a file that needs to be translated but its not a DCT which I like, and in theroy its easier to generate this very simple file format then "inject" internal entities into a DCT which modifies and creates a local version of the origional which I dont like.... Let me know your thoughts.

By the way, I found a whole host of other uses for external entities like assembeling a DCT from a library of reusable controls (something I've always wanted to do.)

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE data-capture-requirements SYSTEM "datacapture6.0.dtd" [
<!ENTITY % local_strings SYSTEM "/iwworkarea/templatedata/components/includes/strings.dtd">
<!ENTITY title SYSTEM "/iwworkarea/templatedata/components/includes/title_field.xml">
<!ENTITY drop_down SYSTEM "/iwworkarea/templatedata/components/includes/drop_down.xml">
%local_strings;
]>
<data-capture-requirements name="Content_Test">
<ruleset name="template_name">
<root-container location="record" name="record">
&title;
&category;
</root-container>
</ruleset>
</data-capture-requirements>

ISCBorisB

[html]

...
[/html]

That's elegant and much better than my original suggestion! Seems practically an ideal in your case. I gave only a passing
thought to the external(probably won't work here) and totally forgot about parameter Entities. As you noted, unless you keep it in
the form of *ready to go* XML in the first place, you'd still have to generate it but it's true shared asset instead of replica's

>>...I found a whole host of other uses for external entities...
You and many others. It's standard XML. That stuff has been discussed on the Forum quite a few times, there are also KB Articles.
For example, in some cases I use it instead of <inline> where the the call is *expensive* and the output is needed in numerous non-replicated DCT items

Tim__D

That's elegant and much better than my original suggestion! Seems practically an ideal in your case. I gave only a passing
thought to the external(probably won't work here) and totally forgot about parameter Entities. As you noted, unless you keep it in
the form of *ready to go* XML in the first place, you'd still have to generate it but it's true shared asset instead of replica's

>>...I found a whole host of other uses for external entities...
You and many others. It's standard XML. That stuff has been discussed on the Forum quite a few times, there are also KB Articles.
For example, in some cases I use it instead of <inline> where the the call is *expensive* and the output is needed in numerous non-replicated DCT items

Thanks for pointing me in the right direction! Are there any best practices for creating and maintaining entities? Scopeing them correctly, naming conventions etc.. are there any links or sites you would recommend?

ISCBorisB

Thanks for pointing me in the right direction! Are there any best practices for creating and maintaining entities? Scopeing them correctly, naming conventions etc.. are there any links or sites you would recommend?

I'm not aware of any non-trivial generic Entities practices/recommendations, it's Application specific.

As far as DCTs are concerned, if I use External Entities at all I try to keep them as "close to the vest" as possible.
For example, if they are type-related I would keep them with datacapture.cfg, Branch-shared DCT Entities directly under
/Branch/SomeArea/templatedata and the like. Normally, there are too few of them to warrant any special considerations,
dedicated maintenance and such.

Sean_Hanck

How timely,

I just finished developing this using the inline mechanism (using TeamSite 6.7.1 SP 1, Windows 2003), but have some testing left to do. I've tried the FormAPI/AJAX method in the past, but always came against roadblocks that could be solved easier with perl before the page is built than with js after the page is built.

At a high level, this is what I did;

1) Identify and store what the user's language preference is as set in their browser, this required a language sniffing cgi inserted as a background image into custom.css.
2) Place the contents of the target dct into a file (I called it a dct snippet).
3) Replace the snippet with my inline command, which loads the dct snippet gets all the strings that I would want translated or localized (these are #text values for "label" and "description" nodes plus "label" attributes of "option" nodes in the xml), I store all my strings in a jrb using an "XPath"ish naming convention that aligns to my dct snippet.

The advantages of this approach versus others that I have done/tried are;

A) You still write the dct using xml, instead of doing a whole bunch of print statements in perl.

It works in Preview
C) It happens before the page is loaded, so no FormAPI lag
D) To support additional locales, I need only to add the corresponding .properties file
E) No requirement for cross browser scripting
F) It is also tied to authoring for multiple languages, so I can add additional authoring languages to my dct by adding locales (I can add French by adding "fr-ca" to the configuration).

The only issue that I think may come in the testing is the handling of Tabs. I'll have to research this, but it is my understanding that Tabs only have name and no label attributes. Changing the name attribute changes the label, but I have yet to investigate how this impacts the data structure.

This is the way I got it to work, and is by no means the only way, I've seen other developers in my group have limited success with FormAPI, but always getting stuck somewhere. The entities method looks good, but I've always had problems detecting the user's language preference (since this is stored in the browser and not in the vpath).

Tim__D

How timely,

I just finished developing this using the inline mechanism (using TeamSite 6.7.1 SP 1, Windows 2003), but have some testing left to do. I've tried the FormAPI/AJAX method in the past, but always came against roadblocks that could be solved easier with perl before the page is built than with js after the page is built.

At a high level, this is what I did;

1) Identify and store what the user's language preference is as set in their browser, this required a language sniffing cgi inserted as a background image into custom.css.
2) Place the contents of the target dct into a file (I called it a dct snippet).
3) Replace the snippet with my inline command, which loads the dct snippet gets all the strings that I would want translated or localized (these are #text values for "label" and "description" nodes plus "label" attributes of "option" nodes in the xml), I store all my strings in a jrb using an "XPath"ish naming convention that aligns to my dct snippet.

The advantages of this approach versus others that I have done/tried are;

A) You still write the dct using xml, instead of doing a whole bunch of print statements in perl.
It works in Preview
C) It happens before the page is loaded, so no FormAPI lag
D) To support additional locales, I need only to add the corresponding .properties file
E) No requirement for cross browser scripting
F) It is also tied to authoring for multiple languages, so I can add additional authoring languages to my dct by adding locales (I can add French by adding "fr-ca" to the configuration).

The only issue that I think may come in the testing is the handling of Tabs. I'll have to research this, but it is my understanding that Tabs only have name and no label attributes. Changing the name attribute changes the label, but I have yet to investigate how this impacts the data structure.

This is the way I got it to work, and is by no means the only way, I've seen other developers in my group have limited success with FormAPI, but always getting stuck somewhere. The entities method looks good, but I've always had problems detecting the user's language preference (since this is stored in the browser and not in the vpath).

Thanks for the feedback. The one problem that I see with your solution that the others also share is that your "snippet" dct cant conatin an <inline />. Thats where using entities really seems to shine. Since you dont use an inline to translate your DCT you can use them as they were intended....to pull data into the form not process the form itself.