Tools for working with signature blocks in multi-language documents

Clause9 Miscellaneous
1

I am a bit struggling with signature blocks in multi-language documents.

One way of doing those would be to have it in one language with translation disabled in the settings for the clause. But then I am left with a single language signature blocks with no tools to make certain parts dependent on whether the document is multi-language or not.

I am wondering whether there are (or can be) tools (e.g. special functions) to approach this issue?

2

Hi Tomas,

What do you think about adding a special-function such as @multi-language? This function would then only return true if the clause is currently being exported to PDF/DOCX and, in addition, multiple languages are being exported.

3

I guess this could be an option.

Alternatively, the existing @english and others could be used but return true also if they are chosen when exporting in multiple languages (currently, I don’t think this is the case).

Also, I am thinking further. While the above could help to deal with static text, it would not work for concepts (variables). As in example below, the function of the signatory will be displayed in the primary language of the document:

|| Buyer in 1 language / {@multi-language: Buyer in 2 language } ||
[…]
|| buyer^signatory-function||
|| Signature in 1 language / {@multi-language: Signature in 2 language } ||

I guess a special function would be required to deal with it as well. Though I guess this is a more difficult case.

4

Hi Tomas,

The @multi-language function is implemented, and will show up in tonight’s version.

I have been investigating your other more advanced scenario, but have some questions before I would proceed with the implementation:

  • At first sight — but to double-check — it’s feasible without changing the fundamentals of the technical architecture to create a special function @in-lang(#buyer^signatory-function, “en”) that would return the value of the datafield in the language specified in the second version (e.g “en” for English or “lt” for Lithuanian), regardless of the language you’re actually working in.
  • This function can function in the Assemble Document mode, because in that mode all available languages are always available. However, in the Q&A mode things get much more complicated. Under the hood, the software exports each language version in a different pass — e.g., first English, then Lithuanian. In each pass, the answers to the Q&A questions get calculated for that language, and then merged into that language’s datafields, following which the document is calculated for that language. Supporting @in-lang for the Q&A is therefore much complicated, because the documents that get created in each pass are not really “aware” of the datafield values in the other passes / languages.
  • This limit to the Q&A mode is also visible towards end-users: while in the data dashboard of Assemble Document you can immediately enter texts in all available languages, this is not the case for a Q&A, where the end-user has to manually switch the language in order to enter data in different languages.
  • You should also take into account that @in-lang would only function for text-datafields. For all the other data types (numbers, dates, durations, etc.) it is currently not possible to set different versions for different languages.
  • Which makes me wonder whether perhaps a more versatile manner to solve your issue, is to simply create a repeating-datafield, and then store the different versions for the different languages in it. Within the Q&A, this would also be easier for the end-user, because he/she will not have to switch languages in order to, for example, enter the signatory’s function in the other language; instead, he/she can simply enter the different language versions in different cells of a table. You can then extract the right version using a combination of the @multi-language and @get special functions.

What do you think?

5

Thanks to the new special function I can quickly solve the issue with static text using the following (and vice versa in the English language clause) :

{ @multi-language: Parašas / Signature | else: Parašas }

Thus, all good with respect to this part.

With respect to a more complicated route suggested by you, I guess it would be rather helpful (despite the manual switch (which is unavoidable) and text-datafields limitations you mentioned) and probably will allow me to do something similar to the following:

{ @multi-language: @in-lang(#first-party^legal-person-representative-position, “lt” ) / @in-lang(#first-party^legal-person-representative-position, “en” ) | else: #first-party^legal-person-representative-position }

With respect to a more versatile route suggested by you, I tried it and it works, but the process is not very straightforward.

6

Hi Tomas,

I just updated the software. The special function (actually called @in-language) is now available for you to try. It should work in both the Q&A and Assemble Document.