Glynn Foster wrote: > Hey, > > Takao Fujiwara - Tokyo S/W Center wrote: > >>Today I investigated bug 6485370 and found many internal patches effect >>.desktop translations. >> >>I guess you can't remove the internal patches from vermillion: >>CASE1: gnome-menus-02-application-submenu-rename.diff >>CASE2: control-center-13-menu-entry.diff >>CASE3: glade-01-menu-entry.diff >>CASE4: dasher-02-menu-entry.diff >>CASE5: evolution-02-menu-entry.diff >>CASE6: ekiga-06-menu-entry.diff >>CASE7: gimp-01-menu-entry.diff >>CASE8: gtkam-01-menu-entry.diff >>CASE9: sound-juicer-02-menu-entry.diff >>CASE10: gnome-desktop-01-jds-about-branding.diff >>CASE11: gnome-terminal-02-menu-entry.diff >> >>Can we separate .desktop/.directory packages from base packages? >>It means the desktop packages are translated by Sun internally. >> >>As you agree, we'll move to use Community translations but I would say >>currently almost .desktop/.directory files uses Sun specific messages. > > > Most of these are because the desktop ui spec introduced changes from the > community versions of them. I also agree we should use community translations > instead of these patches, and encourage any changes in the upstream > translations > if necessary.
OK, I didn't know those patches are expected to upstreamed. As we know JDS 4 may be integrated into S10U4, we would like to think the fixing plan. The desktop menus are high impact so I think it will effect local business. One idea is to change the .desktop strings after translations are merged during the build. Then, English strings only are changed and translations uses community. Another way is same as JDS 3.1 proccess, i.e. we deliver translation tarballs for all modules however we'ld like to avoid this way if possible. Myself would like to separate the package for .destop in case those patches are not upstreamed. > > >>The second problem is to change messages in source codes. >>E.g. JDS gnome-panel has the special timezone dialog but community does not. > > > Right - another patch we'd really like to get upstream. > > >>I'ld like to suggest to separate the translation domain from community. >>In bug 6459568, My suggestion trys to use gnome-panel-jds.mo >>This way can get community translations only but this way requires >>translation tarballs for vermillion. >> >># cd gnome-panel-*/po >># intltool-update -p >> >>Do you have any suggestions? >>We need to get the exact word counts to be translated Sun internally. > > > Can you explain this please - is this for metrics, or because of a real > problem > that you guys have? In preference, I'd like to lower the delta that we're > making > with the community code so that you guys can work with the community > translations directly rather than worrying about what bits and pieces > engineering have changed. I'ld like to separate Sun messages from community ones. Then, if the untranslated messages are community, we can ask community to translate them. If the untranslated messages are Sun, we need to translate them internally. For the internal translation, we need to calculate the word counts because we have paied money to translate them. In JDS 3.1, we just invoke intltool* and get the latest .po files and we can calculate w/c from .po files. In JDS 4, we want to get Sun internal translations only then current patches effect our translation processes. As you know, we need to have some Sun internal messages, e.g. gnome-about. Probably the dead line may be needed when we should wait pathes are upstremed. fujiwara > > > Glynn >
