|
Hi Ed,
Just to clarify a couple of things.
- For the spec doc translations, the work will be handled by the Chinese team (the group has been set up in China with a number of volunteers). I understand the team will read and translate the spec docs (at the moment, we have not talked about the
machine translation involvement, but the doc will be proofread for sure). The translated docs will mention the original English version spec doc is normative - single source of truth. We can figure out the right sentence to add at a later time.
-
During the call, Tanja has proposed the doc will be hosted https://jakarta.ee/zh/specifications/ and it was agreed.
|
Jakarta® Enterprise Edition (EE) 是云原生的未来. Jakarta® EE 开源软件驱动云原生创新, 让企业应用更加现代化，并同时保护Java EE的现有投资.
urldefense.proofpoint.com
|
Thanks
Emily
================
Emily Jiang
Java Champion, Fellow of BCS
STSM, Jakarta and MicroProfile Architect
@IBM
Liberty
Cloud Native Architect & Advocate
LinkedIn: https://www.linkedin.com/in/emilyfhjiang/
From: jakarta.ee-spec.committee <jakarta.ee-spec.committee-bounces@xxxxxxxxxxx> on behalf of Ed Bratt <ed.bratt@xxxxxxxxxx>
Sent: 27 January 2023 02:54
To: Jakarta specification committee <jakarta.ee-spec.committee@xxxxxxxxxxx>; Kenji Kazumura (Fujitsu) <kzr@xxxxxxxxxxx>
Subject: Re: [jakarta.ee-spec.committee] [External] : Agenda for the January 25th Jakarta EE Specification Committee call
API docs, as considered by the Java team are "user documentation. " As with our Specification Documents, our Java Docs serve dual purpose in both describing implementation requirements as well as being the most up to date user documentation.
ZjQcmQRYFpfptBannerStart
This Message Is From an External Sender
This message came from outside your organization.
ZjQcmQRYFpfptBannerEnd
API docs, as considered by the Java team are "user documentation." As with our Specification Documents, our Java Docs serve dual purpose in both describing implementation requirements as well as being the most up to date user documentation. Some Jakarta
EE specifications have almost no Specification narrative and solely rely on the Java Docs to describe the API.
As I view the Japanese Java SE Java Docs, I see there is a mixture of English and Japanese. I do not know how it is decided what is translated and what remains in English. Regardless, we have what we have and, if we decide that translating materials that
are normative is what we want to do, so long as it is clear that any ambiguity is arbitrated by the English artifacts, I'm okay with proceeding.
Glad to hear that the Japanese translations are of good quality. Thank you Kenji for that input.
-- Ed
On 1/26/2023 6:21 PM, Kenji Kazumura (Fujitsu) wrote:
Regarding the JDK translation in Japanese, what Ed describes is almost true.
“Java Language Specification” and “Java Virtual Machine Specification” are not translated.
Because JCK itself is not public, JCK document also is not translated.
But API docs are translated. (i.e. <”https://docs.oracle.com/javase/jp/19/docs/api/index.html”>)
The quality of Japanese translation is not bad so far.
I believe the localized API docs are very helpful to promote Java SE in Japan even if they are informational only.
-Kenji Kazumura
My apologies for missing the Spec. committee meeting yesterday (Jan 25). I'd like to add a couple of points to the material captured in the agenda:
Regarding the specification translation topic (This is just my input, not any commentary on the minutes and since I wasn't at the discussion, if this was covered, forgive me for repeating):
- At an earlier meeting, it was suggested that some
JDK translation work might be considered a reference point for consideration in our discussion about translating the specification documents. I looked further into this and learned that, at least according to the person I discussed this with, the JDK team
only translates what it considers user documentation. There is no translation of JCK or other materials that are required reading by vendors who intend to produce compatible versions of Java SE (as an example, I believe the
language specification document, is only available in English). Furthermore, it is my understanding that this translation begins with a machine translation -- after which, there may be human edits applied but not always. This can lead to translations that
are literal, but not always faithful to the intent behind the written phrases and concepts. (I cannot read Japanese so I would need to defer to other members to tell me if this is actually an issue or not). Machine translation can be especially troubling when
translating between European and Asian languages but native/expert readers will probably find fault, even with European to European machine translations. All that said, I do not object to translation of the Specification documents so long as they are clearly
marked as "informational only" (or something like that). We also need to avoid putting this burden onto the Specification development committer teams and, at least for the foreseeable future as a prerequisite to completing a Specification Release.
- If I had a magic wand, I would recommend that our time and budget be devoted to updating our user oriented documentation: tutorials, user-guides, and samples -- then providing those with translations.
- In the notes, there was text about where to host these documents: I would recommend that the translated specification documents be included at jakarta.ee using the existing page localization features provided
via the site and the Hugo site generation system (e.g.: English page: https://jakarta.ee/specifications/; Chinese localized page: https://jakarta.ee/zh/specifications/). Following this pattern, I believe we can "simply" add page translations as they become available.
- If/when we get to the point where we have translated ancillary material (user guides, samples, tutorials, etc.) we will need to figure out how to provide those materials in an equally 'convenient' fashion
for our users. (For example, the Tutorial pages, today, are not hosted under jakarta.ee. Fortunately, GitHub page templates generally do include mechanisms for hosting localized documentation so, I don't see any barriers to this, moving forward)
Cheers,
-- Ed
On 1/24/2023 4:03 PM, Paul Buck via jakarta.ee-spec.committee wrote:
The agenda for our committee call on Wednesday at 17:00 UTC is here.
Please add any other business items as required.
_______________________________________________
jakarta.ee-spec.committee mailing list
jakarta.ee-spec.committee@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-spec.committee
_______________________________________________
jakarta.ee-spec.committee mailing list
jakarta.ee-spec.committee@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-spec.committee
Unless otherwise stated above:
IBM United Kingdom Limited
Registered in England and Wales with number 741598
Registered office: PO Box 41, North Harbour, Portsmouth, Hants. PO6 3AU
|
