Re: xDoc i18n scalability
Use the tag, eg: HTH, -Lukas Lance Bader wrote: OK. Granted it doesn't work like I want it to work and I should be reluctant to invest in a major enhancement to Maven 1 development. So let's go back to the original questions. If the all the translated text is in a properties file, how do I get the xDoc plugin to place that translated text INSIDE a or element. I understand how the key= attribute replaces the name= attribute, but I don't see a way to specify the inner content. Lance On 2/27/06, Lukas Theussl <[EMAIL PROTECTED]> wrote: I am afraid that, the way it is currently desined, you are supposed to use properties files. I'd need to have a closer look, but it seems to me that it would require quite a substantial re-write of our jelly scripts to make it work the way you suggested. I'd recommend to go with the last option that you mentioned. I'd also like to point out that at this stage of Maven 1 development, we are not sure to work on major enhancements anymore. Unless, of course, someone submits ready-to-apply patches.. -Lukas Lance Bader wrote: I see how to use the xDoc plugin's i18n support to build language dependent navigation menus and titles as well as section and subsection headings. This is GREAT because, as a rule, translators do not translate attribute values. They only translate text between the tags. But how do you replace the content inside section and subsection elements? I must be missing something vital here. (Help me out and I will help you improve your i18n documentation.) I hope the plugin doesn't expect all the translated text to be in a properties file. That is just not scalable. We have 100,000 words on our web site. No one wants a properites file with 100,000 words in it. What I expected (and really really want) is to place translated xDoc XML source files in parallel trees, one tree for each supported language. When a source file in the base language exists in the parallel tree of a supported language, the file from the supported language is used to generate the HTML. Otherwise, the file from the base language is used. That way, Javadoc, XML schema references, code templates and other pages that have not been translated yet, are built from the base language and the XML source documents returned by the translators are used for the translated pages. If you don't have something better, give me a few hints on how to implement this enhancement and I will invest the effort to develop this contribution. If it can't be done, I will just have to build each language dependent site independently and abandon the cute language switching links at the bottom of the navigation pane. Lance - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: xDoc i18n scalability
OK. Granted it doesn't work like I want it to work and I should be reluctant to invest in a major enhancement to Maven 1 development. So let's go back to the original questions. If the all the translated text is in a properties file, how do I get the xDoc plugin to place that translated text INSIDE a or element. I understand how the key= attribute replaces the name= attribute, but I don't see a way to specify the inner content. Lance On 2/27/06, Lukas Theussl <[EMAIL PROTECTED]> wrote: > > > I am afraid that, the way it is currently desined, you are supposed to > use properties files. I'd need to have a closer look, but it seems to me > that it would require quite a substantial re-write of our jelly scripts > to make it work the way you suggested. I'd recommend to go with the last > option that you mentioned. > > I'd also like to point out that at this stage of Maven 1 development, we > are not sure to work on major enhancements anymore. Unless, of course, > someone submits ready-to-apply patches.. > > -Lukas > > > > Lance Bader wrote: > > I see how to use the xDoc plugin's i18n support to build language > dependent > > navigation menus and titles as well as section and subsection headings. > > This is GREAT because, as a rule, translators do not translate attribute > > values. They only translate text between the tags. > > > > But how do you replace the content inside section and subsection > elements? > > I must be missing something vital here. (Help me out and I will help > you > > improve your i18n documentation.) > > > > I hope the plugin doesn't expect all the translated text to be in a > > properties file. That is just not scalable. We have 100,000 words on > our > > web site. No one wants a properites file with 100,000 words in it. > > > > What I expected (and really really want) is to place translated xDoc XML > > source files in parallel trees, one tree for each supported > language. When > > a source file in the base language exists in the parallel tree of a > > supported language, the file from the supported language is used to > generate > > the HTML. Otherwise, the file from the base language is used. That > way, > > Javadoc, XML schema references, code templates and other pages that have > not > > been translated yet, are built from the base language and the XML source > > documents returned by the translators are used for the translated pages. > > > > If you don't have something better, give me a few hints on how to > implement > > this enhancement and I will invest the effort to develop this > contribution. > > > > If it can't be done, I will just have to build each language dependent > site > > independently and abandon the cute language switching links at the > bottom of > > the navigation pane. > > > > Lance > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
Re: xDoc i18n scalability
I am afraid that, the way it is currently desined, you are supposed to use properties files. I'd need to have a closer look, but it seems to me that it would require quite a substantial re-write of our jelly scripts to make it work the way you suggested. I'd recommend to go with the last option that you mentioned. I'd also like to point out that at this stage of Maven 1 development, we are not sure to work on major enhancements anymore. Unless, of course, someone submits ready-to-apply patches.. -Lukas Lance Bader wrote: I see how to use the xDoc plugin's i18n support to build language dependent navigation menus and titles as well as section and subsection headings. This is GREAT because, as a rule, translators do not translate attribute values. They only translate text between the tags. But how do you replace the content inside section and subsection elements? I must be missing something vital here. (Help me out and I will help you improve your i18n documentation.) I hope the plugin doesn't expect all the translated text to be in a properties file. That is just not scalable. We have 100,000 words on our web site. No one wants a properites file with 100,000 words in it. What I expected (and really really want) is to place translated xDoc XML source files in parallel trees, one tree for each supported language. When a source file in the base language exists in the parallel tree of a supported language, the file from the supported language is used to generate the HTML. Otherwise, the file from the base language is used. That way, Javadoc, XML schema references, code templates and other pages that have not been translated yet, are built from the base language and the XML source documents returned by the translators are used for the translated pages. If you don't have something better, give me a few hints on how to implement this enhancement and I will invest the effort to develop this contribution. If it can't be done, I will just have to build each language dependent site independently and abandon the cute language switching links at the bottom of the navigation pane. Lance - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
xDoc i18n scalability
I see how to use the xDoc plugin's i18n support to build language dependent navigation menus and titles as well as section and subsection headings. This is GREAT because, as a rule, translators do not translate attribute values. They only translate text between the tags. But how do you replace the content inside section and subsection elements? I must be missing something vital here. (Help me out and I will help you improve your i18n documentation.) I hope the plugin doesn't expect all the translated text to be in a properties file. That is just not scalable. We have 100,000 words on our web site. No one wants a properites file with 100,000 words in it. What I expected (and really really want) is to place translated xDoc XML source files in parallel trees, one tree for each supported language. When a source file in the base language exists in the parallel tree of a supported language, the file from the supported language is used to generate the HTML. Otherwise, the file from the base language is used. That way, Javadoc, XML schema references, code templates and other pages that have not been translated yet, are built from the base language and the XML source documents returned by the translators are used for the translated pages. If you don't have something better, give me a few hints on how to implement this enhancement and I will invest the effort to develop this contribution. If it can't be done, I will just have to build each language dependent site independently and abandon the cute language switching links at the bottom of the navigation pane. Lance
