Hi.
When compiling lastest POs in SVN with msgfmt tool, I found some POs generates two kinds of errors : - `msgid` and `msgstr` entries do not both end with `\n`. - `msgid` and `msgstr` entries do not both start with `\n`.
After reviewing source of the tool, I found that msgfmt tool does some layout checking and warns error when: - msgid starts(ends) with newline, but msgstr starts(ends) without newline - msgid starts(ends) without newline, but msgstr starts(ends) with newline.
A quick fix for the exporter is attached. I think also some qualificaton procedure on build time might be needed if LaunchPad doesn't have validation for this.
PO and line numbers with problem are attached below. (Takashi, could you please fix them in SVN?):
--- From here EToys/fr.po:480 Morphic/Demo/de.po:62 Morphic/Flaps/ja.po:268 Morphic/Kernel/de.po:401, 356, 1823, 1834, 1966 Morphic/PDA/pt.po:15 Morphic/Scripting/de.po:1036 Morphic/Scripting/fr.po:836, 1085 Morphic/Scripting/ja.po:175 Morphic/Support/ja.po:65 Morphic/Windows/ja.po:27 Multilingual/de.po:126 ST80/ja.po:15 System/ja.po:39 Tools/de.po:287 --- To here
/Korakurider
-------------------------------------- Easy + Joy + Powerful = Yahoo! Bookmarks x Toolbar http://pr.mail.yahoo.co.jp/toolbar/
Thanks!
Are you aware of our discussions regarding reducing the number of translation files? While modularity is valuable, it makes live harder for translators and maintainers. Not sure who is going to work on this - you or Takashi? I filed a ticket anyway:
https://dev.laptop.org/ticket/3816
- Bert -
On Sep 26, 2007, at 11:29 , korakurider wrote:
Hi.
When compiling lastest POs in SVN with msgfmt tool, I found some POs generates two kinds of errors :
- `msgid` and `msgstr` entries do not both end with `\n`.
- `msgid` and `msgstr` entries do not both start with
`\n`.
After reviewing source of the tool, I found that msgfmt tool does some layout checking and warns error when:
- msgid starts(ends) with newline, but msgstr starts(ends)
without newline
- msgid starts(ends) without newline, but msgstr
starts(ends) with newline.
A quick fix for the exporter is attached. I think also some qualificaton procedure on build time might be needed if LaunchPad doesn't have validation for this.
PO and line numbers with problem are attached below. (Takashi, could you please fix them in SVN?):
--- From here EToys/fr.po:480 Morphic/Demo/de.po:62 Morphic/Flaps/ja.po:268 Morphic/Kernel/de.po:401, 356, 1823, 1834, 1966 Morphic/PDA/pt.po:15 Morphic/Scripting/de.po:1036 Morphic/Scripting/fr.po:836, 1085 Morphic/Scripting/ja.po:175 Morphic/Support/ja.po:65 Morphic/Windows/ja.po:27 Multilingual/de.po:126 ST80/ja.po:15 System/ja.po:39 Tools/de.po:287 --- To here
/Korakurider
Hi, Bert.
--- Bert Freudenberg bert@freudenbergs.de wrote:
Are you aware of our discussions regarding reducing the number of translation files? While modularity is valuable, it makes live harder for translators and maintainers. Not sure who is going to work on this - you or Takashi? I filed a ticket anyway:
I know, but... As in the previous discussion thread, I think more important questions would be a) for the lookup of #translated, how to know correct domain of the receiver of #translated. without this b) can't be executed in real. b) how MOs/textdomains are packaged
After determing them we can formulate how to package POs, I think. (We have been discussing about PO first. But I think we need to think about textdomain first)
My current understanding is right now we don't have good strategy for a). I come to deadlock around there... Possible workaround Takashi proposed recently is that we use just only one domain for whole etoys system. I think that is not bad, especially for FRS. How do you think?
/Korakurider
-------------------------------------- Easy + Joy + Powerful = Yahoo! Bookmarks x Toolbar http://pr.mail.yahoo.co.jp/toolbar/
Hi Bert, Korakurider,
I think using just one domain is reasonable compromise for First Deployment. I don't think we can test enough text domain support in #translated for this limited time. Because String is a essential system class.
But still we can cheat as if text domain is supported. Instead of changing text domain dynamically, other domain can be override. For example, when you load BotsInc, MO file for BotsInc overrides original one.
Although a number of PO files can be independent to MO file, I am working about one big PO file. Actually original GetTextExporter generates just a PO file. But I want to merge it with Korakurider's GetTextExporter2 because there are a lot of common code.
Cheers, - Takashi
korakurider wrote:
Hi, Bert.
--- Bert Freudenberg bert@freudenbergs.de wrote:
Are you aware of our discussions regarding reducing the number of translation files? While modularity is valuable, it makes live harder for translators and maintainers. Not sure who is going to work on this - you or Takashi? I filed a ticket anyway:
I know, but... As in the previous discussion thread, I think moreimportant questions would be a) for the lookup of #translated, how to know correct domain of the receiver of #translated. without this b) can't be executed in real. b) how MOs/textdomains are packaged
After determing them we can formulate how to packagePOs, I think. (We have been discussing about PO first. But I think we need to think about textdomain first)
My current understanding is right now we don't havegood strategy for a). I come to deadlock around there... Possible workaround Takashi proposed recently is that we use just only one domain for whole etoys system. I think that is not bad, especially for FRS. How do you think?
On Sep 26, 2007, at 12:09 , korakurider wrote:
Hi, Bert.
--- Bert Freudenberg bert@freudenbergs.de wrote:
Are you aware of our discussions regarding reducing the number of translation files? While modularity is valuable, it makes live harder for translators and maintainers. Not sure who is going to work on this - you or Takashi? I filed a ticket anyway:
I know, but... As in the previous discussion thread, I think moreimportant questions would be a) for the lookup of #translated, how to know correct domain of the receiver of #translated. without this b) can't be executed in real.
Can we use the class category as text domain, and if the translation is not found there, fall back to the one in global file?
b) how MOs/textdomains are packaged After determing them we can formulate how to packagePOs, I think. (We have been discussing about PO first. But I think we need to think about textdomain first)
My current understanding is right now we don't havegood strategy for a). I come to deadlock around there... Possible workaround Takashi proposed recently is that we use just only one domain for whole etoys system. I think that is not bad, especially for FRS. How do you think?
If this prevents a deadlock for now, yes.
- Bert -
--- Bert Freudenberg bert@freudenbergs.de wrote:
a) for the lookup of #translated, how to knowcorrect
domain of the receiver of #translated. without
this b)
can't be executed in real.
Can we use the class category as text domain, and if the translation is not found there, fall back to the one in global file?
By specification of gettext, each domain has its MO (file name of MO includes domain name). One PO can't include msgs for multiple domains. So we will have still too many POs as long as class categories are used for domain, I think. Do you have reduction target for number of domains?
/Korakurider
-------------------------------------- Easy + Joy + Powerful = Yahoo! Bookmarks x Toolbar http://pr.mail.yahoo.co.jp/toolbar/
On Sep 27, 2007, at 13:36 , korakurider wrote:
--- Bert Freudenberg bert@freudenbergs.de wrote:
a) for the lookup of #translated, how to knowcorrect
domain of the receiver of #translated. without
this b)
can't be executed in real.
Can we use the class category as text domain, and if the translation is not found there, fall back to the one in global file?
By specification of gettext, each domain has its MO (file name of MO includes domain name). One PO can't include msgs for multiple domains. So we will have still too many POs as long as class categories are used for domain, I think.
No, what I meant is that we look up twice. First in the domain provided by the class, and if not found, in the default domain.
We would only provide one po file for the default domain. But the mechanism above means someone could amend the system-provided translations with their own files.
Say, in Object we have "translationDomainFor: aSelector" returning 'default' (or 'Squeak' or 'Etoys' or whatever our default domain is). Then a class wishing to override the translation domain could do so, we would not even have to hard-code the category name as translation domain. Or we could change that method in Object to look at the category later.
Don't you see some mechanism to allow additional translations is necessary?
Do you have reduction target for number of domains?
For now let's just have one.
- Bert -
Thank you for validation of PO files, I'll merge them.
For po files written by translators, I use msgmerge to validate it. So I think this procedure works well.
Cheers, - Takashi
A quick fix for the exporter is attached. I think also some qualificaton procedure on build time might be needed if LaunchPad doesn't have validation for this.
PO and line numbers with problem are attached below. (Takashi, could you please fix them in SVN?):
etoys-dev@lists.squeakfoundation.org
-
Bert Freudenberg -
korakurider -
Takashi Yamamiya