RE: [External Email] Re: [docbook-apps] UI strings vs manual strings ?
"Riffel, Patrick" <[email protected]> Tue, 20 Dec 2022 13:39:04 +0000
| Newsgroups | gmane.text.docbook.apps |
|---|---|
| Message-ID | <AM6PR03MB41836EC4A3E8A5486ADF6A89EEEA9@AM6PR03MB4183.eurprd03.prod.outlook.com> |
--_004_AM6PR03MB41836EC4A3E8A5486ADF6A89EEEA9AM6PR03MB4183eurp_
Content-Type: multipart/alternative;
boundary="_000_AM6PR03MB41836EC4A3E8A5486ADF6A89EEEA9AM6PR03MB4183eurp_"
--_000_AM6PR03MB41836EC4A3E8A5486ADF6A89EEEA9AM6PR03MB4183eurp_
Content-Type: text/plain; charset=WINDOWS-1252
Content-Transfer-Encoding: quoted-printable
Hi all,
the issue of keeping UI strings and documentation in sync sounds familiar a=
nd I'd like to let you know how we've been doing it for last 12 years or so=
- not perfect but robust enough to publish several dozen documents with up=
to 1300 pages in two (was four) languages as PDF and webhelp.
The software we are writing documentation for is using dozens of XML files =
for its configuration and user interface. Each UI string comes with an ID t=
hat is more or less unique, and we can therefore reuse it in our documentat=
ion. However, almost every configuration file has a slightly different cont=
ent model to the one before and therefore we have to pre-process everything=
before we can actually use it.
In this pre-processing step, a script pulls together all the UI strings fro=
m all the different configurations into a "normalized" xml file. This step =
also pulls in the translated versions of strings. You end up with a rather =
big xml file ("alltext.xml"), in which you have the ID, the original string=
and translations in one place. If a translation is missing, we add a place=
holder text.
On the Docbook side, we are using guilabel/guimenu/guimenuitem to tag UI te=
xt. By our convention, each of these elements must have a @remap attribute =
with its value set to one of the IDs you can find in the software configura=
tion files (or rather in that big xml file from the previous step). Referen=
cing the ID is the important bit for the automation. For readability, the T=
echnical Writer would also use the UI string as content for guilabel/guimen=
u/guimenuitem. However, this isn't strictly necessary as the element's cont=
ent will be replaced at a later stage.
Our publishing process is automated via ant/jenkins. Once all xincludes hav=
e been resolved, we use some XSLT on the resulting temporary file and repla=
ce the UI strings with the most recent versions from "alltext.xml". And tha=
t's more or less it - an ID-based lookup and string replacement.
To assist our Technical Writers, we also provide modified versions of the s=
oftware configuration. This configs can be used to run the software in a wa=
y that will display the internal ID alongside the UI text. By doing this, t=
he Technical Writer is provided with sufficient context to find the right I=
D to be used for @remap. It also helps to avoid confusion where the configu=
ration files have several copies of the same UI string but with different I=
D values.
Since the UI strings are translated separately and keep their original ID, =
the remapping also works when we are publishing in other languages (our pri=
mary language is German, and we translate into English. This process has be=
en used in the past to translate into French, Italian and Russian as well).
A word on the authoring process: We are using oXygen XML and have put toget=
her some schematron rules that will flag up when a remap attribute is missi=
ng or when the content of a guilabel is different from the current value in=
the lookup file. This was done as a proof-of-concept and isn't required fo=
r authoring, but we encourage using it. We are also experimenting with sche=
matron quickfixes to replace UI strings where necessary - this also is expe=
rimental and not a feature we are using all the time, but it comes in handy=
every now and then.
We do most of our translation inhouse (we used OmegaT in the past, but not =
anymore, sorry!). The documentation and the UI strings are translated separ=
ately (by the same Translator) into two separate translation memories. When=
translating the documentation, all guilabel/guimenu/guimenuitem are set to=
be non-translatable. However, our Translator sees the element content and =
thus has all the context information they need. Once they export their file=
s to the target language, the UI strings will still be in German. The Germa=
n text is then replaced via a combination of @lang and @remap when publishi=
ng to their respective output format.
For those cases where UI text does need to be translated/localized, a Techn=
ical Writer can set a @translate attribute to "yes" on guilabel elements an=
d override the replacement. The TMS will unlock those elemetns and the Tran=
slator can modify the content of those elements.
I am aware that this process might be problematic with certain languages an=
d/or if the source material is not well maintained and probably
for many other reasons, too. We had trouble in the past with UI text that w=
as split into several individual strings or when placeholders are
being used. With regards to mnemonics and shortcuts - those are indeed anno=
ying. Our specific problem is that the software configuration wasn't design=
ed to be translation friendly, and we basically have to strip away things b=
efore going into translation. I do believe that this problem could be solve=
d if we put in some effort in redesigning the configuration files. Screensh=
ots also matter and need manual updates when the UI text changes.
Bottom line is: We manage to keep our documentation and user interface sync=
hronized in terms of UI strings. It took a while to get to this level and w=
e still haven't solved every issue but for the most part, it works. On top =
of that, the Technical Writers and our Dev team are constantly sharing info=
rmation. Developers also need to consult the Technical Writers and Translat=
or before adding or changing any UI text - that way we have more control ov=
er terminology and consistency.
I hope that helps and you get some ideas out of this.
Regards
Patrick
[Quadient]
Patrick Riffel
Team Leader Information Development
[email protected]<mailto:[email protected]>
+49 711 806098-0
Hauptst=E4tter Stra=DFe 70
70178 Stuttgart
www.quadient.com<https://www.quadient.com/>
Learn more about Quadient<https://www.quadient.com/connections>
Quadient DOPiX Germany GmbH ist ein beim Amtsgericht Stuttgart eingetragene=
s Unternehmen.
Registernummer: HRB 17655
Sitz der Gesellschaft: Hauptst=E4tter Stra=DFe 70, 70178 Stuttgart
Gesch=E4ftsf=FChrer: Andreas Schwegler, Duncan Spanner, Laurent du Passage
--_000_AM6PR03MB41836EC4A3E8A5486ADF6A89EEEA9AM6PR03MB4183eurp_
Content-Type: text/html; charset=WINDOWS-1252
Content-Transfer-Encoding: quoted-printable
<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Diso-8859-=
1">
<meta name=3D"Generator" content=3D"Microsoft Word 15 (filtered medium)">
<!--[if !mso]><style>v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style><![endif]--><style><!--
/* Font Definitions */
@font-face
=09{font-family:"Cambria Math";
=09panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
=09{font-family:Calibri;
=09panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
=09{margin:0cm;
=09font-size:11.0pt;
=09font-family:"Calibri",sans-serif;}
span.EmailStyle19
=09{mso-style-type:personal-reply;
=09font-family:"Calibri",sans-serif;
=09color:windowtext;}
.MsoChpDefault
=09{mso-style-type:export-only;
=09font-size:10.0pt;}
@page WordSection1
=09{size:612.0pt 792.0pt;
=09margin:70.85pt 70.85pt 2.0cm 70.85pt;}
div.WordSection1
=09{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=3D"DE" link=3D"blue" vlink=3D"purple" style=3D"word-wrap:break-w=
ord">
<div class=3D"WordSection1">
<p class=3D"MsoNormal"><span lang=3D"EN-GB" style=3D"mso-fareast-language:E=
N-US">Hi all,
<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-GB" style=3D"mso-fareast-language:E=
N-US"><o:p> </o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-GB" style=3D"mso-fareast-language:E=
N-US">the issue of keeping UI strings and documentation in sync sounds fami=
liar and I'd like to let you know how we've been doing it for last 12 years=
or so - not perfect but robust enough
to publish several dozen documents with up to 1300 pages in two (was four)=
languages as PDF and webhelp.
<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-GB" style=3D"mso-fareast-language:E=
N-US"><o:p> </o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-GB" style=3D"mso-fareast-language:E=
N-US">The software we are writing documentation for is using dozens of XML =
files for its configuration and user interface. Each UI string comes with a=
n ID that is more or less unique, and
we can therefore reuse it in our documentation. However, almost every conf=
iguration file has a slightly different content model to the one before and=
therefore we have to pre-process everything before we can actually use it.
<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-GB" style=3D"mso-fareast-language:E=
N-US"><o:p> </o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-GB" style=3D"mso-fareast-language:E=
N-US">In this pre-processing step, a script pulls together all the UI strin=
gs from all the different configurations into a "normalized" xml =
file. This step also pulls in the translated versions
of strings. You end up with a rather big xml file ("alltext.xml"=
), in which you have the ID, the original string and translations in one pl=
ace. If a translation is missing, we add a placeholder text.<o:p></o:p></sp=
an></p>
<p class=3D"MsoNormal"><span lang=3D"EN-GB" style=3D"mso-fareast-language:E=
N-US"><o:p> </o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-GB" style=3D"mso-fareast-language:E=
N-US">On the Docbook side, we are using guilabel/guimenu/guimenuitem to tag=
UI text. By our convention, each of these elements must have a @remap attr=
ibute with its value set to one of the
IDs you can find in the software configuration files (or rather in that bi=
g xml file from the previous step). Referencing the ID is the important bit=
for the automation. For readability, the Technical Writer would also use t=
he UI string as content for guilabel/guimenu/guimenuitem.
However, this isn't strictly necessary as the element's content will be re=
placed at a later stage.
<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-GB" style=3D"mso-fareast-language:E=
N-US"><o:p> </o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-GB" style=3D"mso-fareast-language:E=
N-US">Our publishing process is automated via ant/jenkins. Once all xinclud=
es have been resolved, we use some XSLT on the resulting temporary file and=
replace the UI strings with the most
recent versions from "alltext.xml". And that's more or less it -=
an ID-based lookup and string replacement.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-GB" style=3D"mso-fareast-language:E=
N-US"><o:p> </o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-GB" style=3D"mso-fareast-language:E=
N-US">To assist our Technical Writers, we also provide modified versions of=
the software configuration. This configs can be used to run the software i=
n a way that will display the internal
ID alongside the UI text. By doing this, the Technical Writer is provided =
with sufficient context to find the right ID to be used for @remap. It also=
helps to avoid confusion where the configuration files have several copies=
of the same UI string but with
different ID values.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-GB" style=3D"mso-fareast-language:E=
N-US"><o:p> </o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-GB" style=3D"mso-fareast-language:E=
N-US">Since the UI strings are translated separately and keep their origina=
l ID, the remapping also works when we are publishing in other languages (o=
ur primary language is German, and we
translate into English. This process has been used in the past to translat=
e into French, Italian and Russian as well).
<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-GB" style=3D"mso-fareast-language:E=
N-US"><o:p> </o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-GB" style=3D"mso-fareast-language:E=
N-US">A word on the authoring process: We are using oXygen XML and have put=
together some schematron rules that will flag up when a remap attribute is=
missing or when the content of a guilabel
is different from the current value in the lookup file. This was done as a=
proof-of-concept and isn't required for authoring, but we encourage using =
it. We are also experimenting with schematron quickfixes to replace UI stri=
ngs where necessary - this also
is experimental and not a feature we are using all the time, but it comes =
in handy every now and then.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-GB" style=3D"mso-fareast-language:E=
N-US"><o:p> </o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-GB" style=3D"mso-fareast-language:E=
N-US">We do most of our translation inhouse (we used OmegaT in the past, bu=
t not anymore, sorry!). The documentation and the UI strings are translated=
separately (by the same Translator) into
two separate translation memories. When translating the documentation, all=
guilabel/guimenu/guimenuitem are set to be non-translatable. However, our =
Translator sees the element content and thus has all the context informatio=
n they need. Once they export their
files to the target language, the UI strings will still be in German. The =
German text is then replaced via a combination of @lang and @remap when pub=
lishing to their respective output format.
<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-GB" style=3D"mso-fareast-language:E=
N-US"><o:p> </o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-GB" style=3D"mso-fareast-language:E=
N-US">For those cases where UI text does need to be translated/localized, a=
Technical Writer can set a @translate attribute to "yes" on guil=
abel elements and override the replacement. The
TMS will unlock those elemetns and the Translator can modify the content o=
f those elements.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-GB" style=3D"mso-fareast-language:E=
N-US"><o:p> </o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-GB" style=3D"mso-fareast-language:E=
N-US">I am aware that this process might be problematic with certain langua=
ges and/or if the source material is not well maintained and probably
<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-GB" style=3D"mso-fareast-language:E=
N-US">for many other reasons, too. We had trouble in the past with UI text =
that was split into several individual strings or when placeholders are
<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-GB" style=3D"mso-fareast-language:E=
N-US">being used. With regards to mnemonics and shortcuts - those are indee=
d annoying. Our specific problem is that the software configuration wasn't =
designed to be translation friendly, and
we basically have to strip away things before going into translation. I do=
believe that this problem could be solved if we put in some effort in rede=
signing the configuration files. Screenshots also matter and need manual up=
dates when the UI text changes.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-GB" style=3D"mso-fareast-language:E=
N-US"><o:p> </o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-GB" style=3D"mso-fareast-language:E=
N-US">Bottom line is: We manage to keep our documentation and user interfac=
e synchronized in terms of UI strings. It took a while to get to this level=
and we still haven't solved every issue
but for the most part, it works. On top of that, the Technical Writers and=
our Dev team are constantly sharing information. Developers also need to c=
onsult the Technical Writers and Translator before adding or changing any U=
I text - that way we have more control
over terminology and consistency.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-GB" style=3D"mso-fareast-language:E=
N-US"><o:p> </o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-GB" style=3D"mso-fareast-language:E=
N-US">I hope that helps and you get some ideas out of this.<o:p></o:p></spa=
n></p>
<p class=3D"MsoNormal"><span lang=3D"EN-GB" style=3D"mso-fareast-language:E=
N-US"><o:p> </o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-GB" style=3D"mso-fareast-language:E=
N-US">Regards<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-GB" style=3D"mso-fareast-language:E=
N-US">Patrick<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"mso-fareast-language:EN-US"><o:p>&nbs=
p;</o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"mso-fareast-language:EN-US"><o:p>&nbs=
p;</o:p></span></p>
<div>
<table class=3D"MsoNormalTable" border=3D"0" cellspacing=3D"0" cellpadding=
=3D"0" width=3D"550" style=3D"width:412.5pt">
<tbody>
<tr style=3D"height:118.5pt">
<td width=3D"130" style=3D"width:97.5pt;padding:0cm 10.5pt 0cm 10.5pt;heigh=
t:118.5pt">
<p class=3D"MsoNormal" align=3D"center" style=3D"text-align:center"><img wi=
dth=3D"97" height=3D"130" style=3D"width:1.0104in;height:1.3541in" id=3D"Pi=
cture_x0020_1" src=3D"cid:[email protected]" alt=3D"Quadient">=
<o:p></o:p></p>
</td>
<td width=3D"420" style=3D"width:315.0pt;border:none;border-left:solid #FF4=
200 1.0pt;padding:0cm 0cm 0cm 15.0pt;height:118.5pt">
<p class=3D"MsoNormal"><b><span lang=3D"EN-GB" style=3D"font-size:13.5pt;fo=
nt-family:"Arial",sans-serif;color:#FF4200;text-transform:upperca=
se">Patrick Riffel<o:p></o:p></span></b></p>
<p class=3D"MsoNormal" style=3D"margin-bottom:6.0pt"><span lang=3D"EN-GB" s=
tyle=3D"font-family:"Arial",sans-serif">Team Leader Information D=
evelopment<o:p></o:p></span></p>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:6.0pt;margin-right:0cm;m=
argin-bottom:6.0pt;margin-left:0cm">
<span style=3D"font-size:8.5pt;font-family:"Arial",sans-serif;col=
or:#4A4A4A"><a href=3D"mailto:[email protected]"><span style=3D"color:#=
4A4A4A">[email protected]</span></a><o:p></o:p></span></p>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:6.0pt;margin-right:0cm;m=
argin-bottom:6.0pt;margin-left:0cm">
<span style=3D"font-size:8.5pt;font-family:"Arial",sans-serif;col=
or:#4A4A4A">+49 711 806098-0<o:p></o:p></span></p>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:6.0pt;margin-right:0cm;m=
argin-bottom:6.0pt;margin-left:0cm">
<span style=3D"font-size:8.5pt;font-family:"Arial",sans-serif;col=
or:#4A4A4A">Hauptst=E4tter Stra=DFe 70<br>
70178 Stuttgart<o:p></o:p></span></p>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:6.0pt;margin-right:0cm;m=
argin-bottom:6.0pt;margin-left:0cm">
<u><span style=3D"font-size:8.5pt;font-family:"Arial",sans-serif;=
color:#4A4A4A"><a href=3D"https://www.quadient.com/" target=3D"_blank"><spa=
n lang=3D"EN-GB" style=3D"color:#4A4A4A">www.quadient.com</span></a></span>=
</u><u><span lang=3D"EN-GB" style=3D"font-size:8.5pt;font-family:"Aria=
l",sans-serif;color:#4A4A4A"><o:p></o:p></span></u></p>
<p class=3D"MsoNormal" style=3D"margin-top:6.0pt"><span style=3D"font-size:=
9.0pt;font-family:"Arial",sans-serif"><a href=3D"https://www.quad=
ient.com/connections" target=3D"_blank"><span lang=3D"EN-GB" style=3D"color=
:#FF4200">Learn more about Quadient</span></a></span><span lang=3D"EN-GB" s=
tyle=3D"font-size:9.0pt;font-family:"Arial",sans-serif"><o:p></o:=
p></span></p>
</td>
</tr>
</tbody>
</table>
<p class=3D"MsoNormal"><span lang=3D"EN-GB"><o:p> </o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:8.0pt;font-family:"Ari=
al",sans-serif;color:#FF4200">Quadient DOPiX Germany GmbH ist ein=
beim Amtsgericht Stuttgart eingetragenes Unternehmen.<br>
Registernummer: HRB 17655<br>
Sitz der Gesellschaft: Hauptst=E4tter Stra=DFe 70, 70178 Stuttgart<br>
Gesch=E4ftsf=FChrer: Andreas Schwegler, Duncan Spanner, Laurent du Passage<=
/span><o:p></o:p></p>
</div>
<p class=3D"MsoNormal"><o:p> </o:p></p>
</div>
</body>
</html>
--_000_AM6PR03MB41836EC4A3E8A5486ADF6A89EEEA9AM6PR03MB4183eurp_--
--_004_AM6PR03MB41836EC4A3E8A5486ADF6A89EEEA9AM6PR03MB4183eurp_
Content-Type: image/png; name="image001.png"
Content-Description: image001.png
Content-Disposition: inline; filename="image001.png"; size=3418;
creation-date="Tue, 20 Dec 2022 13:39:04 GMT";
modification-date="Tue, 20 Dec 2022 13:39:04 GMT"
Content-ID: <[email protected]>
Content-Transfer-Encoding: base64
iVBORw0KGgoAAAANSUhEUgAAAJYAAADICAYAAAF9gijzAAAAGXRFWHRTb2Z0d2FyZQBBZG9iZSBJ
bWFnZVJlYWR5ccllPAAADPxJREFUeNrtXYuRhKoSNQRDMARDsG4EhmAIhmAGhmAIE4IhTAiGYAi8
9RXey7KAgHwaPV1F1e4Mg83xQDfNr6pSCPunYqYUpBApdaEKOtPuVNDVg7210uX3qp7hN03IwpgP
8MutwmwfiMLcCnNqAa6FfX0Lc2roV9+Zeo7WtTXY9GvL7ULKFUNXzeR/JkM5tfR/JxXgVNiVNr8K
m4oAORhZ2e0WcFgXHyPs3Miv8t6qmuLzKWRhXjYzTWE/qQ9mmf6fl2Rh4Q1wCJsZtLAgNtO5fXpZ
c4+m9Q3Rr+3Ptr+dTabBYHCZYA873gky1ye2voVlt6uD64gmliK757g2vOP5U0AdUpnbrdvX9t18
/XNQhVx5FNSbCsknZ/QPKKko5h1qKUqxCBVcqSrGqCo2kVQsWHcRWLHvHcMcTbGgvX8gxT7RbGUy
byO0uxMl7hZKyVSe7OGzrQoFNuNsCsQwwrmL3CwMiaaLcOMu5JVjlYyP4Tqu1KT4fhL+/0rlqMr9
U1uVYqsmiLqqyhAUY4qHMpsw8aH5pojwMv5QpvlM9fliQOxjqdim+mJCE8k4+K2phANUaUsa9/fy
SKnEKG7byAQxCkZOoZhrLlwCJ97B3znWK0jqy4dASrvSJTZnvCpHQSnvObrYIyIo5RRKOkaxxJRi
VaoeO7VSbfAQUo7YKJSCUjmUasgpFSpwG1CphpxSXmv+kikVyusMPog43FFySoUYyUQbamVSqg46
9gug1BxjlHzHdVmoxRN6KmGgoFMkNYnYVGDk0k2X/DxsvN2iIBALqskN41FKMWHCRjWxo5pSa03T
b5IyX8VE0yR89mc5JdPUlF18dvY9jer3BoTOzzcduq5KrbbzgYJSq4Tirpgxu6WU+NkJeXuhVKtB
zKiUOJG4CxnECcpGkXc2TVBKr0/8vr1Qar9sPST7mbdNZA6aRRjGnal8VqR9IiBN7LU+xXpNvmPt
iGmlBtBEDKC8i7xyzzlHSEsKgNrCQYq/pSnRlo+c6RsKqBTWrCHSRbQlsGkh1J9urg8bSrZwKRcy
TSX1NzEt9WMYlQKsKAu/ngyWsg8r1ewneukt5TEdNbDYI4YurwRLquzieSBYE90XfAs7SGydBVgA
C2Bl31r/ErA6730kbwOLjHIFgLXYLsp5PVikBtLEwapJRR4Ig9XHDss+Baye2kQFVbBqn8B//zaw
yM8+EwEr7Hrgh4IVdyqfYDyL5noHqVIfitGBbCd8OAC3EgaoqagKn/rfM4Izlb5kso7QF223NiBB
IBBIvA0DncnPA0QasFTLySM+27g8vKuqKPsmjzJrh7ydJVitAqwjb+PwrObiRf2Ssfq76+wQ084y
m4J3xWdNpT7wcdeUyzTNUPalNsXvW/7ZqChvsfi9EiwTjWdPsOaqMi6dFvMuFnlNYE1CHlWSt4FN
tixyBWvyBOvDmVlZ5t1ugLVc/L4KCdasybgomkxd/d7cKVZYtWvxa2haNnl3y2bINOwMziwRiImD
1F4wqeEgr1KfoJKh+rtrUmdEeiGvcuvnRaBO1GvQgKeT0dC6rIzTVFXwY2ylkRgBgdAN17R8MYpr
zOsIMA5PB6eOFFffHwNe4qVMO+nwsQGkLXPMfSgBpJXkaj1iIFHeSbZTAqqU+cIpJ0gl7vfZcwC1
FAhU+hA0M9yijmn830DtDwHq3m77FwIVZx3Eg5pe3CaZaMgy5HZlQkUHirJONzZo7kU4nIQc5dn3
gdsLwXLvvzJ55y0RsOheXkV0pfNgCxTOool5A9lD9ypOj2JV7lOOcGKITd8V+bSNZx0JRWCSoSiw
cHCPjVdf8vmjKV489Sks0mDh/Czb+UeAdZk+AMvjhKP+SWDFmqajNAc43mRGE7suZCyhgh09SQZT
PV4cYDncMwGwABbAAlgAq3zXoSiwJoBlD1YHsMo5tRtgPQysGWD5rA7MHHkgDxalOcOywMqsHHWw
RkqLbEmDZdpACbBsF4cALIfViCzPXWFkwaK4mI0qWIMNWD3AcliEC7ActgsntozUwHLfaZEwKEgK
LOrbUSiB1d8Bq34RWPfvkk4QSSUBVinHpGQHq6Qd91nXOhR3REEux7jUMx2W1KxKebZDyasFs5wa
UhcI1Cf3wT2lHGPQVhSE+CaplephY9Or+6YCQdsZhbt1PIdKqc6wWaqnCHc3Qu9pXIpkkSfrZgcA
j/ja+ApwIBAIBAKB3PU0BJfjU+TB0znA0oSfJ0CUH6xjlXILsOyfqy37GEp0EdA8y7WRrvp7CdsV
WKPns67yasFiitRW6puXVHIUKgfaWkWZW/X3lqVDBo0Of56pmXBoDb+X9W8U+b4XWPz6Up6/ayr9
NVU2YJ3XZMmrfY/nyDfOnc+SrdqiyKsCy/QspiFFrfh9e8WswQDAcAMsVukvUpRfwvG3bjLBBqz9
4lmD9L8qcrEpyvgD1l5VxsDZHbAqQ15mmbezAMt0Xd/XUq/VBixm0cmFBqtzAKuyBMuUppBgzYnB
GhzAai3BuuuGWIE1GwpoNGDVFg8z+Sh7ZX/n4GYJ1pwCrPPDxaIjPiu6afKKK+d6DbCDotxOk7dT
mm71hbVM4x/uIZuhaDpPC7YJVsR0qewqmGfVPN0i+Faf6vdltEyT97Rsrn7WJPzmI5TxvcGsj6C/
si9ZLd/EmXe58Pjr6r+bLHupL9KNx+RbLzsJLFOUYaz+3rwpf6/Ts9EYo+FuhwgBWAArmayAACIa
jI6niaeZz4DbpFn4XUfymkBIFMJMxA74XU8S4g3RJ1CvmSArbnnwra1WkNu90PoAErn0cOjdIhBp
KPW6iEhpw1IFPyI1DzFrKc1nA+aoydS+4BLTJDu8yexOykim+mW+Ug7frH4ToUa8dAJH8D2od4Kp
o2Eq66f4TjteKL1zB4r0xUAoEAwmD4m2iXxQ7GmhEBfi8bzUp81/KBGqfwihZsKWIDXB+twVfozZ
K8DNKO84Tc+J4Kf5GQ2IdfNc6ZsVnB/sxA4gVgY3ASO+fCaY6rXCIcIIiEu9m1hhzwMEqUCs4OQC
qUCsKOTCyk0Qy7SS1ZdUWCsFYoU9zfvhIQUQK0cogq9MwEsHscJe1gC/CsQK7m9h2TCIFWX5M140
iBXjxnb0ViBW+F4LvhWIFdzXeugymFJSa0GqpqD6dKLiE17wr42ePZ/OqvnfsYPFg4FUQ2H4TYiy
O673Bk6O0XiA8ThfhwaWAMN+zgtYgVggFogFYoFYIBbIA2KBWLmJtYFYIFbw6DviMyBWrDjWBDBA
rBiR9xbEArGizH2+3ByCWLFwLHCyE8Qq5eyLF29OBbECbGKtHrREA8Qq5aSel54oA2LFPommsNWK
IBaN1NiCN4BYIFYQE0jgQFUQq7y04GAQECvvgSAv3RYGYoXcUg9ygVjZSPUSswhipTB/L3ToQaxY
jvoLrzgBsexTmitQ2PMOvQWxNPN/LMetYOw5R0qCWH9T3kur+BTQDmI9qpeic69Q4dNAIJbP9Exi
gi0gFkZ8INi7DwUph1AFE2y1qMsXhKJHsFLOON24v9jxNDxoSmusnip8qxnuPUy4upPZHPD/MJKN
DLeLxQoZjBUEu7GD70KGaOcjNxDFyh/swRj/eckJJvNfEzdlmb97CdmGlwwAvqSj4S/p1Q6yfQom
0YfXAb1RQeGNkQdqt8z+0MJ1afFm3tfzdUIauU+jSqOUFz0NBAKBQCAQCAQCgbxZjqmVUTPabAyj
y39HmYAQouQPT52CWBMmkSHBiWX80e9rk0EsCIgl1BkNAsTKS6wDnI/wQzFtvKBayHscxbwanNrd
kdUuv6l5vs1C15rXy2aXb/OTFg0GjH/X2BKLn9azq+YJhakjeVpo+ElfxbN3xfN1MvE615blTlJe
+b2sQhJxPj9TDkIW6SHHCxCBaPlnu1TB8ze6ipm+N/3GtHOmFfQ48w7885q/YFnX0UKXQQL7wwEV
iTxIRB4siGXbK8n12rjeHU+DgvCLRa+yCOWeDa7j5Oz4M3ap3rKMFsSa5VYvvoDGsqfYpQqmItYi
vVQbXTcLXV3LrRQ9+x1iTTfqtWt6GlsCitbK1sRd5vsIyrnKlphYl72DQb4GXe6UOwcgVi+U0Xu+
g4/h5bsc8rFaWAwrYt3x7ofExLKt9FVrDFluFYBYH4M/Z5u2QO82OLEGD0B7ECsIse4+P2SnEYxY
p4n4eij+jUCsxVAxsbzGUVfTQONOuWMAYo03nk+WWI2Q6euhgIk4vWOP2Fj4Bd8Lh/XKD2IW5bYe
pLrrvIt4uixf7gxhgqzEOkcYX4lgnaYSqzQsveqRJotyG6ms1aH32QxlLtKo6EpXOeQyGGJnYgMI
FW6YLONKtSJvLmJtNg28VrRuOa1Ci3IxdVflnmW7mIJREfaQHdrewsdyLXeXgoG2xBodeqH1Aqur
gKaol8vqicWSWLUi0OoTWQjmQ0EgIBYExIKAWBAIBOIo/wPstgJNev0zSAAAAABJRU5ErkJggg==
--_004_AM6PR03MB41836EC4A3E8A5486ADF6A89EEEA9AM6PR03MB4183eurp_--