This is a dup of 323252 in bugsplat, as we are moving all 5.0 bugs over to bugzilla. Basically just need a comment from guha here on why this is no longer relevant ------------------------------------------------- Some scheme for separating localizable strings from RDF text is essential for localization of Navigator Chrome, and probably also SmartMail. Support for either external or internal entity definitions in the RDF parser (as defined in the XML 1.0 specification) would accomplish this for us. Text requiring localization would then be separable into a header file or header section with statements that looked like: <!ENTITY chrome.GuideButton.label "Guide"> <!ENTITY chrome.GuideButton.url "http://guide.netscape.com/"> and would be used in parameter values or in element content as parameter strings like: "Guide string is &chrome.GuideButton.label;" HREF = "&chrome.GuideButton.url;" This would allow L10n groups in Dublin and Mountain View to create much more intelligent tools to reuse translations, track changes in the Chrome, and prepare materials for translator and engineers to prepare, maintain and fix. We are open to other schemes for accomplishing the same goal, but at this point in the Gromit development cycle, the help of the RDF engineering team is urgently needed to get a workable scheme spec'ed and implemented. ------- Additional Comments From relliott 09/18/98 10:58 ------- Guha, you aren't winning any allies over here: if you marked this bug WONTFIX because you won't implement the external entities, I think you should note that the solution is different than that suggested and accept the bug. The issue remains (for now) that RDF is not localizable, we're just debating the solution. If you'd rather we submit a new bug with the same description but a different solution, we can do that, but you need to let us know what works best for you. ------- Additional Comments From guha 09/20/98 10:18 ------- Ok, I am changing the description of the bug. Rick --- you need to talk to jar to find out whether he will accept changes to the client or whether this should be all server-side ------- Additional Comments From jar 09/21/98 16:39 ------- Not facilitating internationalization seems like a big problem, and a critical feature. Please size up the design and schedule ASAP for consideration. To the extent to which internationalization can be done server side... that is helpful... but I think Rick was stressing that certain client side separation was needed to facilitate this work. ------- Additional Comments From relliott 10/13/98 11:06 ------- Reopening this bug; I submitted the spec for externalizing strings to Guha over a week ago. Note to all concerned: current plan is to create externalized string property files for the localizable RDF and rebuild the localized files using a server based process. We need to review this procedure LONG before we go live to build our L10n process around it (you can't wait until beta to make this happen). ------- Additional Comments From paulmac 01/12/99 13:43 ------- Per guha, no longer relevant. ------- Additional Comments From msanz 01/13/99 17:06 ------- Paul, Guha, can you add more info as to why this is no longer relevant? I'm reopening it just to get that info into the bug report. Thanks. ------- Additional Comments From paulmac 01/14/99 16:46 ------- I must defer to guha here for the explanation. ------- Additional Comments From leger 01/21/99 12:44 ------- Can we put a bug in Buzilla for this one, and get it closed out of Bugsplat?

Since we are now using the same parser as Raptor, this bug is no longer relevant.

verified, one parser fits all