TW 2.1 beta 7 and translations
PauloSoares
small problems:
1) I couldn't find where to translate the message 'TiddlyWiki startup
in x milliseconds';
2) the messages in the 'Log' column of the PluginManager are not
translated until the translation plugin is executed. Of course, if I
rename that plugin to make sure it is the first one that is executed
the problem is solved but maybe there is a more elegant solution.
Udo Borkowski
Regarding 1): The message 'TiddlyWiki startup in x milliseconds' is just
included in the beta for debugging/profiling purpose and will be removed
in the final release.
Regarding 2) This is an issue I was not aware of (and I guess, Jeremy,
too). For now go ahead and choose a "proper" name to make the
translation plugin be executed first. In a later revision we should come
up with "a more elegant solution". I raised a ticket to cover this
(http://trac.tiddlywiki.org/tiddlywiki/ticket/171). Thanks for pointing
out this problem.
Udo
----------
Udo Borkowski
http://www.abego-software.de
PauloSoares
thanks for you answer.
> Regarding 1): The message 'TiddlyWiki startup in x milliseconds' is just
> included in the beta for debugging/profiling purpose and will be removed
> in the final release.
Too bad it's going away because I was really liking that message as a
way to evaluate TW's performance as I keep adding plugins. Would it be
a bad thing to keep it as an option?
I've found another issue regarding the translation of shadow tiddlers:
most of those tiddlers can keep their original names but other ones
need to be translated. For example, the 'GettingStarded' tiddler is
replaced by a tiddler titled 'ComoComeçar', in portuguese. However,
the 'GettingStarded' tiddler is still created and I end up with 2
shadow tiddlers when only the translated one is needed. Is there a way
to avoid this kind of duplication?
Cheers,
Paulo Soares
Udo Borkowski
Regarding 1): The message 'TiddlyWiki startup in x milliseconds' is just included in the beta for debugging/profiling purpose and will be removed in the final release.Too bad it's going away because I was really liking that message as a way to evaluate TW's performance as I keep adding plugins. Would it be a bad thing to keep it as an option?
I've found another issue regarding the translation of shadow tiddlers: most of those tiddlers can keep their original names but other ones need to be translated. For example, the 'GettingStarded' tiddler is replaced by a tiddler titled 'ComoComeçar', in portuguese. However, the 'GettingStarded' tiddler is still created and I end up with 2 shadow tiddlers when only the translated one is needed. Is there a way to avoid this kind of duplication?
delete config.shadowTiddlers.GettingStarted;
merge(config.shadowTiddlers,{
DefaultTiddlers: "ComoComeçar",
MainMenu: "ComoComeçar",
"ComoComeçar": "... the GettingStarted text in portuguese..."});
The delete will remove the "unused" GettingStarted tiddler
Bob Denny
> Too bad it's going away because I was really liking that message as a
> way to evaluate TW's performance as I keep adding plugins. Would it be
> a bad thing to keep it as an option?
I strongly vote in favor of this as well. I know... complexity vs ease
of use. I suggest it be a URI query string command for developers.
Saq Imtiaz
It would be relatively simple to implement this as a paramifier.... There isnt much code overhead, so why not?
Cheers,
Saq
PauloSoares
> >I've found another issue regarding the translation of shadow tiddlers:
> >most of those tiddlers can keep their original names but other ones
> >need to be translated. For example, the 'GettingStarded' tiddler is
> >replaced by a tiddler titled 'ComoComeçar', in portuguese. However,
> >the 'GettingStarded' tiddler is still created and I end up with 2
> >shadow tiddlers when only the translated one is needed. Is there a way
> >to avoid this kind of duplication?
> >
> Have you tried this?
>
> delete config.shadowTiddlers.GettingStarted;
Thanks Udo, that does it.
In a related subject: I was translating the content and also the names
of a few other shadow tiddlers (AdvancedOptions, OptionsPanel, etc)
when I remembered that some plugins access and may even change the
originally titled shadow tiddlers. Because of this it is not possible
to fully translate TW! Has this problem been discussed before or
addressed in any way?
Jeremy Ruston
> of a few other shadow tiddlers (AdvancedOptions, OptionsPanel, etc)
> when I remembered that some plugins access and may even change the
> originally titled shadow tiddlers. Because of this it is not possible
> to fully translate TW! Has this problem been discussed before or
> addressed in any way?
Not really; I've been convincing myself that it's OK for there to be a
skeleton of untranslateable phenomena (like shadow tiddler names and
macro names), in the same way that the actual keywords of a
programming language like Java are not translated...
Having said that I realise that many of the shadow tiddlers are very
user visible and so this does need sorting out. Happily, the
dependencies between the core code and shadow tiddler names are very
narrow. For instance, one could change the PageTemplate to use
MenuDeMainos and AdvanceOptionelle quite happily (using a made-up
language), and then allow for a degree of backwards compatibility by
embedding in each of them <<tiddler MainMenu>> and <<tiddler
AdvancedOptions>>. That would at least make sure that any content
inserted by a plugin would be visible...
Cheers
Jeremy
--
Jeremy Ruston
mailto:jer...@osmosoft.com
http://www.tiddlywiki.com
Udo Borkowski
This (optional) field can contain an internationalized string. At various locations in the code we could then use the "label" rather than the title as a caption for the the tiddler (if it is defined).
I.e. I would define a function
function getLabelOrTitle(tiddler) {So the "title" is still the way to (technically) identify the tiddler, but the label may be used for rendering a "user readable identification" of the tiddler. When no label is defined (the normal case) the title is used for this purpose.
var s = store.getValue(tiddler,"label");
return !s ? tiddler.title : s;
}
This approach requires some more evaluation, especially when to use the title and when the label/title. But it may be a very powerful extension since it could also be used for other issues than translations, like "renaming" a tiddler to give it a more "user friendly name" etc.
Any comments?
Clint Checketts
I've been going this way with some of my plugins since it allows for duplicate tiddler names. It's been useful.
-Clint
Daniel Baird
> So the "title" is still the way to (technically) identify the tiddler, but
> the label may be used for rendering a "user readable identification" of the
> tiddler. When no label is defined (the normal case) the title is used for
> this purpose.
I like this idea, but "label" seems to imply that it's less for
presentation that "title". Maybe call it "preferredTitle", or
"presentationTitle", or something like that?
;D
--
Daniel Baird
http://tiddlyspot.com (free, effortless TiddlyWiki hosting)
http://danielbaird.com (TiddlyW;nks! :: Whiteboard Koala :: Blog ::
Things That Suck)
Udo Borkowski
I like this idea, but "label" seems to imply that it's less for presentation that "title". Maybe call it "preferredTitle", or "presentationTitle", or something like that?
Choosing a field name like "...Title" also makes it more obvious that this is related to the "title" of the tiddler.
PauloSoares
should remain but they would be rendered under an optional title
defined in a field. This way developers could still rely on the
original names but these would stay away from the users' eyes. Looks
good to me!
Anyway, I guess that any change regarding this issue won't make it to
TW2.1 so I'll stick to Jeremy's tip for now.
Another issue:
-> merge(config.options,{txtUserName: "YourName"});
If the above code goes into the lingo tiddler it replaces the
txtUserName read from the cookies. Is there any other way to translate
this default txtUserName?
--
Paulo Soares
PauloSoares
I've just noticed that you included my portuguese translation in
http://www.tiddlywiki.com/. Thanks for doing that but I have two
further requests:
1) to avoid the risk of upseting some fine Brasiian people I suggest
that you replace 'TiddlyWiki em Português' with 'TiddlyWiki em
Português Europeu' (that's European Portuguese);
2) move the link to my site to the first group as I am not a Brasilian.
Cheers,
Paulo Soares
Eric Shulman
>
> If the above code goes into the lingo tiddler it replaces the
> txtUserName read from the cookies. Is there any other way to translate
> this default txtUserName?
add a conditional so that the merge is only performed if the username
value is still equal to "YourName", in which case it is safe to assume
that there wasn't a saved cookie value so you are free to overwrite the
username with the default value from your lingo tiddler.
if (config.options.txtUserName=="YourName")
merge(config.options,{txtUserName: "SomeOtherDefaultName"});
HTH,
-e
Eric Shulman
TiddlyTools / ELS Design Studios
PauloSoares
> add a conditional so that the merge is only performed if the username
> value is still equal to "YourName", in which case it is safe to assume
> that there wasn't a saved cookie value so you are free to overwrite the
> username with the default value from your lingo tiddler.
>
> if (config.options.txtUserName=="YourName")
> merge(config.options,{txtUserName: "SomeOtherDefaultName"});
Nice and easy, thank you Eric!
--
Paulo Soares
Bob McElrath
> My idea on this issue is a new (extended) field called "label".
This is very similar to what ZW has to do...it has an "id" field which
is just the title, translated into a restricted character set that is
compatible with zope ID's. And, actually, TW 2.1's field names is an
even more restricted character set. So if an id/label were used, it
could simultaneously be used as a handle for server-sides, or filesystem
name if tiddlers are stored as individual files in a filesystem (as ZW
essentially does). Since the id refers to a specific zope object, this
is how renames are tracked...since the object is renamed it tracks the
history under the old title too.
This zope id field is currently hidden from the user, and not put into
an extended field. Though, I think it would be a good idea to do so,
but I never thought anyone else would want to see it...
The ID transformation has to be unique and reversible to the title
though. e.g. if I can make two tiddlers, 'Foo Bar' and 'Foo Bar' (note
extra space), they better map to two different ID's.
--
Cheers,
Bob McElrath [Univ. of California at Davis, Department of Physics]
Somewhere, something incredible is waiting to be known. - Carl Sagan
Jeremy Ruston
Cheers
Jeremy
Jeremy Ruston
I'd definitely like to explore this idea more; do you think you could
create a ticket for it for consideration for 2.2?
Cheers
Jeremy
Saq Imtiaz
> My idea on this issue is a new (extended) field called "label".
The one minor concern that I have with this, is that it might get confusing when I try to create a TiddlyLink to a tiddler with label "Saq's Tiddler", and it doesnt work since the tiddler title is Saq'sTiddler..... so either there should be an easy way to tell when looking at a tiddler that its using a label, and what its really title is.... or TiddlyLinks should support labels too. The latter might lead to all sorts of problems of its own though.
Cheers,
Saq
Jeremy Ruston
> when I try to create a TiddlyLink to a tiddler with label "Saq's Tiddler",
> and it doesnt work since the tiddler title is Saq'sTiddler..... so either
> there should be an easy way to tell when looking at a tiddler that its using
> a label, and what its really title is.... or TiddlyLinks should support
> labels too. The latter might lead to all sorts of problems of its own
> though.
I think TiddlyLinks would have to support labels as well. In fact, I
suspect that this whole label idea is actually equivalent to an
earlier (and often repeated) suggestion that TiddlyWiki support
aliases for tiddler names. (So that you can have 'formatter' and
'formatters' refer to the same tiddler, for insance).
Saq Imtiaz
You're right, it does seem almost the same as aliases. The significant difference would be that the alias would be used as the "visible" title.
Saq
Jeremy Ruston
> difference would be that the alias would be used as the "visible" title.
One way of thinking about it is to have the concept of a 'preferred
alias' which is distinct from the title (which would remain as the
unique ID).
Bob McElrath
> > I think TiddlyLinks would have to support labels as well. In fact, I
> > suspect that this whole label idea is actually equivalent to an
> > earlier (and often repeated) suggestion that TiddlyWiki support
> > aliases for tiddler names. (So that you can have 'formatter' and
> > 'formatters' refer to the same tiddler, for insance).
>
>
> You're right, it does seem almost the same as aliases. The significant
> difference would be that the alias would be used as the "visible" title.
Well these id's would have a restricted character set. So they can't be
true aliases... This is more akin to a "unique identifier" and need not
even be readable, really.
Saq Imtiaz
Saq Imtiaz [lew...@gmail.com] wrote:
> > I think TiddlyLinks would have to support labels as well. In fact, I
> > suspect that this whole label idea is actually equivalent to an
> > earlier (and often repeated) suggestion that TiddlyWiki support
> > aliases for tiddler names. (So that you can have 'formatter' and
> > 'formatters' refer to the same tiddler, for insance).
>
>
> You're right, it does seem almost the same as aliases. The significant
> difference would be that the alias would be used as the "visible" title.
Well these id's would have a restricted character set. So they can't be
true aliases... This is more akin to a "unique identifier" and need not
even be readable, really.
Umm, Bob I think the idea was to provide alternative readable labels for tiddlers, to facilitate translations and friendlier titles.
Cheers,
Saq
Bob McElrath
> Umm, Bob I think the idea was to provide alternative readable labels for
> tiddlers, to facilitate translations and friendlier titles.
Ok, so I got off on my own tangent. But then we have a confusing set of
ways to identify a tiddler:
"Title"
"Label" (possibly multiple of these -- multiple languages, for instance)
"id" (used by server-sides and future undo/revision code)
"unique identifier" which keeps popping up in discussions...
Seems to me we can reduce this to a set of two: an "id" (which is also a
unique identifier) and a set of labels.
But then what happens when someone using a spanish translation, for
which MainMenu is PrincipalLista, decides to create a tiddler called
"MainMenu" anyway?
So this seems to me to suggest that id's and labels be totally
disconnected...somehow...
Daniel Baird
> which MainMenu is PrincipalLista, decides to create a tiddler called
> "MainMenu" anyway?
I think we'd have to prevent the creation of the new MainMenu tiddler,
same as you're prevented now from creating another tiddler with a
duplicated title.
Saq Imtiaz
On 9/19/06, Bob McElrath <bob.mc...@gmail.com> wrote:
>
> But then what happens when someone using a spanish translation, for
> which MainMenu is PrincipalLista, decides to create a tiddler called
> "MainMenu" anyway?
I think we'd have to prevent the creation of the new MainMenu tiddler,
same as you're prevented now from creating another tiddler with a
duplicated title.
Wouldnt really be a problem since the tiddler MainMenu would already exist, just with a different label. You would probably get a message like: "The tiddler PricipalLista (MainMenu) already exists, do you want to overwrite it?"
Saq
Daniel Baird
> > On 9/19/06, Bob McElrath <bob.mc...@gmail.com> wrote:
> > >
> > > But then what happens when someone using a spanish translation, for
> > > which MainMenu is PrincipalLista, decides to create a tiddler called
> > > "MainMenu" anyway?
>
> just with a different label. You would probably get a message like: "The
> tiddler PricipalLista (MainMenu) already exists, do you want to overwrite
> it?"
I think that's the way around Bob meant it.. the user tries to create
PrincipaLista. That's what I thought I read, anyway.. ;D
Daniel Baird
>
> So then not being able to create "MainMenu" in a spanish TW becomes a
> magic, obscure behavior that surprises users. I don't like that at all.
>
Well I guess the only solution I can think of is to have a list
somewhere of what the MainMenu tiddler, and other "presentation"
system tiddlers, are really called.
config.systemtiddlers.MainMenu = "MainizzleMenizzit"
Then, whenever the system or plugins want the getting started tiddler,
they have to check the systemtiddlers list and find out what it's
called (including resolving the [[TiddlerName]] inclusions in
templates).
This might actually work better for translating "special" tags like
excludeSearch, but it seems crazy.. it would make it very difficult to
copy modifications from someone else's TiddlyWiki, coz someone who's
speaking Shizzit could copy someone else's AdvancedOptions, but it
doesn't work for them coz it's not called AdvizzitOpshizzle or
whatever.
Is there another option I can't think of?
Jeremy Ruston
these problems.
First, we can make reduce the number of direct references to "magic"
tiddlers like DefaultTiddlers by embedding those names in the
PageTemplate. So, there would still be a few special tiddlers whose
names couldn't be translated, but they're all pretty much system stuff
that end-users should only see through the abstraction of a theme
switcher
So, "DefaultTiddlers" would become a macro reference in the
PageTemplate, something like macro="openTiddlersRecursive
DefaultTiddlers", and therefore could be freely translated into
something else.
Then to deal with the ordering of translations, rather than bringing
in a fiddly system for control systemConfig ordering (which I'd like
to do eventually), I think we should make translations be done via
tiddler slices, rather than systemConfig. They could be installed
before plugins are processed, solving the problem of translating
plugin processing error strings.
We could allow for multiple simultaneous translations (eg for
authoring vs. viewing) by processing lingo from tiddlers tagged
"systemLingo", and a new txtOption for the current lingo if there's
more than one available.
Finally, to deal with the problem of plugins that need to append stuff
to "AdvancedOptions" etc., we could establish conventions that plugins
look at a specific named lingo item to get the name of, say, the
SideBarOptions.
What do you reckon?
Cheers
Jeremy
On 9/19/06, Daniel Baird <danie...@gmail.com> wrote:
>
Udo Borkowski
a) Now a translator has to deal with a complete tiddler when translating (and PageTemplate is a complex one) rather than just dealing with strings or words.
b) People cannot deploy different PageTemplates without getting into trouble with translations.
c) One can no longer refer to the "DefaultTiddler" from a plugin (e.g. to programmatically change the tiddlers to be opened "initially", as in a plugin that trys to re-open the tiddlers that were last opened/saved)
Overall I think we should stick to the "magic tiddlers" (and implement the "displayedTitle" feature)
Regarding "make translations be done via tiddler slices, rather than systemConfig.": probably this will help for a lot of stuff, when translating just text. But sometimes translation really involves "real code", like deleting some fields etc (for an example see the current thread). So maybe this "translation tiddler" should contain one or more "special slices" (like "initialTranslateCode" or "finalTranslateCode"). So this may require a lot of extra coding. Since we should provide a "plugin ordering mechanism" in 2.2 anyhow maybe it is sufficient to stick to the old "code based" approach. This also has the benefit that existing "translations plugins" don't need to be rewritten.
Notice that also this codebased approach easily allows "multi translations" and switching translations (by just (re-)executing the "new translation" given in the "txtOptionLingo").
So I guess
Udo Borkowski
do you think you could create a ticket for it for consideration for 2.2?
Jeremy Ruston
> (and PageTemplate is a complex one) rather than just dealing with strings or
> words.
I agree it would be nicer to maintain the current approach where the
templates don't (usually) need to get translated. But this is a
problem we have already: to change the name of the MainMenu requires a
change to the PageTemplate.
Thinking about it, a solution might be to add a level of indirection
to the names of the magic tiddlers:
config.systemTiddlers.defaultTiddlers = "DefaultTiddlers";
> b) People cannot deploy different PageTemplates without getting into
> trouble with translations.
As I say, this is already a problem.
> c) One can no longer refer to the "DefaultTiddler" from a plugin (e.g. to
> programmatically change the tiddlers to be opened "initially", as in a
> plugin that trys to re-open the tiddlers that were last opened/saved)
Yes they can if they look up the name of the tiddler as above.
> Overall I think we should stick to the "magic tiddlers" (and implement the
> "displayedTitle" feature)
I think the displayedTitle feature is really too complicated, and has
a lot of unexpected side effects (as we've discussed). I'd much rather
find a solution that was simpler and easier to understand, even if
it's not such a 'complete' solution.
> Regarding "make translations be done via tiddler slices, rather than
> systemConfig.": probably this will help for a lot of stuff, when translating
> just text. But sometimes translation really involves "real code", like
> deleting some fields etc (for an example see the current thread).
I think that translations that involve coding are the exception rather
than the rule, and we should treat the coding aspects of them as
ordinary plugins.
My goal here is to make the process of creating and maintaining
translations be much, much less 'code' intensive.
> So maybe
> this "translation tiddler" should contain one or more "special slices" (like
> "initialTranslateCode" or "finalTranslateCode"). So this may require a lot
> of extra coding.
This subverts the principle that plugin code only gets executed
through the single call to loadPlugins(). The extra pass that I've
proposed to extract translation lingo from slices shouldn't have to
repeat the execution checks that loadPlugins() does.
> Since we should provide a "plugin ordering mechanism" in
> 2.2 anyhow maybe it is sufficient to stick to the old "code based" approach.
I disagree. The plugin ordering mechanism is (relatively) complex and
fiddly, and shouldn't be something that translators have to worry
about.
> This also has the benefit that existing "translations plugins" don't need to
> be rewritten.
They wouldn't need to be rewritten under my proposal; processing the
translation slices would insert them into the 'config' object as at
present. A plugin could therefore continue to modify or overwrite
those values as at present.
Cheers
Jeremy
Udo Borkowski
Check if there is a tiddler with a "title" we are looking for.
Only if not look for a tiddler with a "displayTitle" that matches.
Regarding the alias issue: even though it looks similiar to the problem currently discussed (both problems deal with one tiddler and multiple "titles") the alias idea is a little different and needs to be handle differently. I guess this is worth a separate discussion/ticket ?
Jeremy Ruston
> currently discussed (both problems deal with one tiddler and multiple
> "titles") the alias idea is a little different and needs to be handle
> differently. I guess this is worth a separate discussion/ticket ?
Can you expand on the differences?
Udo Borkowski
This also has the benefit that existing "translations plugins" don't need to be rewritten.They wouldn't need to be rewritten under my proposal; processing the translation slices would insert them into the 'config' object as at present. A plugin could therefore continue to modify or overwrite those values as at present.
I.e. assume we have the current (JavaScript) translation plugin "PortugueseLingo". What does a translator have to do to make it fit into the newly proposed approach? And what does he has to do if it contains "real code" like the already mentioned "delete" statement?
Jeremy Ruston
> translation slices would insert them into the 'config' object as at
> present. A plugin could therefore continue to modify or overwrite
> those values as at present.
>
> I don't understand that. Can you re-phrase this?
My proposal is to add into main() a call to a function called
processLingo(), just before invokeParamifier() is called.
processLingo() would scan through any tiddlers tagged 'systemLingo'
and enumerate the tiddler slices in them. Each slice would be of the
form:
|messages.nothingSelected:|Nothing is selected. You must select one or
more items first|
processLingo() would extract the name and value, and plug the value
into the associated member of 'config'.
Subsequently, loadPlugins() would still be called as at present.
There's nothing to stop a plugin also overwriting
config.messages.nothingSelected.
> I.e. assume we have the current (JavaScript) translation plugin
> "PortugueseLingo". What does a translator have to do to make it fit into the
> newly proposed approach?
Well, the purpose of the backwards compatibility aspect is to ensure
that translators don't *have* to update to the new approach.
Anyway, creating a new-style translation from scratch would be a case
of importing a blank lingo tiddler, filling it in, and tagging it
appropriately.
> And what does he has to do if it contains "real
> code" like the already mentioned "delete" statement?
Then they would need a plugin to handle the "real code".
Udo Borkowski
But I still don't see the advantage of this new "tiddler slice" approach (beside the tiddler looks nicer).
Wouldn't it be simpler (catching up the first step of you proposal) and execute all tiddlers tagged with "systemLingo" prior to the "normal" systemConfig stuff.
Udo
Jeremy Ruston
> (beside the tiddler looks nicer).
That's part of the motivation, to make life easier for translators.
> Wouldn't it be simpler (catching up the first step of you proposal) and
> execute all tiddlers tagged with "systemLingo" prior to the "normal"
> systemConfig stuff.
If we do that, we'll start an arms race with other things that also
want to be executed first. You can guarantee that other, non-lingo
plugins would use the "systemLingo" tag.
I do have a solution in mind for the plugin ordering problem, though,
but we should tackle that in a separate thread. As I've said, it's
necessarily complicated, and therefore I'd prefer it to be something
that's not exposed to everyone who's doing translations.
Cheers
JEremy