WordPress.org

GlotPress

Opened 5 years ago

Last modified 5 months ago

#97 assigned enhancement

Glossary

Reported by: nbachiyski Owned by: yoavf
Milestone: 1.0 Priority: normal
Version: Component: General
Keywords: has-patch 2nd-opinion Cc: contato@…, jenia@…, info@…, stephen@…, deckerweb.mobil@…, pavelevap@…, hewsut@…

Description

For every language translators should be able to define a list of terms and their translations. This list is ideal for terms, which need standardization like File, Feed, and other strings, whose translations aren't obvious.

Then, in the interface the user should be able to query the Glossary while in the translation editor.

Attachments (32)

97.diff (27.8 KB) - added by yoavf 17 months ago.
97.1.diff (27.8 KB) - added by yoavf 17 months ago.
Fix an issue with creating a new glossary in previous patch.
create glosssary.png (39.7 KB) - added by yoavf 17 months ago.
description.png (43.2 KB) - added by yoavf 17 months ago.
create entry.png (41.8 KB) - added by yoavf 17 months ago.
view glossary.png (48.6 KB) - added by yoavf 17 months ago.
97.2.diff (31.3 KB) - added by yoavf 17 months ago.
97.3.diff (36.0 KB) - added by yoavf 17 months ago.
97.4.diff (35.9 KB) - added by yoavf 17 months ago.
glossary.png (64.2 KB) - added by yoavf 17 months ago.
edit entry.png (83.3 KB) - added by yoavf 17 months ago.
add entry.png (69.4 KB) - added by yoavf 17 months ago.
97.5.diff (38.2 KB) - added by yoavf 17 months ago.
97.6.diff (38.3 KB) - added by yoavf 17 months ago.
97.7.diff (37.9 KB) - added by yoavf 17 months ago.
since last patch: ui improvements
glossary_suggested_translations.png (42.6 KB) - added by jenia 17 months ago.
How glossary suggestions would look like
97.8.diff (34.4 KB) - added by markoheijnen 17 months ago.
Small HTML fixes
97.9.diff (38.4 KB) - added by yoavf 17 months ago.
added modified glossary.js
Screen Shot 2014-02-18 at 15.30.12 .png (16.4 KB) - added by yoavf 17 months ago.
97.10.diff (54.9 KB) - added by yoavf 17 months ago.
97.11.diff (55.7 KB) - added by yoavf 17 months ago.
Fix for jittery tooltips, and some other minor fixes
97.12.diff (55.7 KB) - added by yoavf 17 months ago.
fixes a small JS issue with the tooltips
97.13.diff (55.7 KB) - added by yoavf 17 months ago.
Prevents warning on translation set view if no glossary exists
97.14.diff (55.7 KB) - added by yoavf 17 months ago.
Fix some permissions issues
97.15.diff (62.2 KB) - added by yoavf 17 months ago.
97.15.1.diff (62.8 KB) - added by yoavf 17 months ago.
bump css/js versions
97.16.diff (63.7 KB) - added by yoavf 17 months ago.
Add meta information to the glossary entry editing form
glossary_hierarchy.diff (6.2 KB) - added by yoavf 15 months ago.
glossary_hierarchy.2.diff (6.0 KB) - added by yoavf 13 months ago.
wp-dev-rhg-glossary.csv (70.2 KB) - added by haroonyousuf 11 months ago.
Rohingya Glossary
97-glossary-highlight.png (35.3 KB) - added by netweb 7 months ago.
wp-dev-rhg-glossary.2.csv (148 bytes) - added by haroonyousuf 6 months ago.

Download all attachments as: .zip

Change History (119)

comment:1 @waclawjacek3 years ago

This would be absolutely great. At the moment I have to make such a list on my own. Translators should also be able to suggest additions to the glossary.

comment:2 @defries3 years ago

  • Milestone changed from Future Release to 1.0

comment:3 @markoheijnen2 years ago

  • Milestone changed from 1.0 to 1.1

comment:4 @yoavf18 months ago

  • Owner changed from somebody to yoavf
  • Status changed from new to assigned

My initial thoughts on this:

Schema and structure

  • We'll add two table gp_glossaries and gp_gloassary_items.
  • A glossary will be linked to a translation set, so will inherit a link to a project/language
  • A glossary can have a parent glossary, which would be useful when we want to create a separate glossary for a sub project, that will also include entries from the parent project.
  • A glossary item will include the term, it's morphological type (verb/noun), possible examples, comments, and suggestion translation.

Here are very early schemas for the tables:

CREATE TABLE IF NOT EXISTS `gp_glossaries` (
  `glossary_id` int(10) NOT NULL AUTO_INCREMENT,
  `translation_set_id` int(10) NOT NULL,
  `parent_glossary_id` int(10) DEFAULT NULL,
  PRIMARY KEY (`glossary_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 AUTO_INCREMENT=1 ;
CREATE TABLE IF NOT EXISTS `gp_glossary_items` (
  `item_id` int(10) NOT NULL AUTO_INCREMENT,
  `glossary_id` int(10) NOT NULL,
  `term` varchar(255) NOT NULL,
  `type` varchar(255) DEFAULT NULL,
  `examples` text,
  `comment` text,
  `suggested_translation` varchar(255) DEFAULT NULL,
  `last_update` datetime DEFAULT NULL,
  PRIMARY KEY (`item_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 AUTO_INCREMENT=1 ;

UI

Viewing: I'm thinking a floating window/sidebar that will open via an always visible link (inside the translation set view). The window will list all items in the glossary, with a quick search box.
Need to figure out how exactly this will look, since the examples and comment fields could be quite long.
There should be a way to quickly search for originals containing the original term, and translations containing the suggested translation.

comment:5 @yoavf18 months ago

  • Milestone changed from 1.1 to 1.0

comment:6 follow-ups: @markoheijnen18 months ago

Not sure if parent_glossary_id is needed. I guess we could use the project structure for it. So maybe it's a check if sub projects should inherit the glossary.

Check also http://codex.wordpress.org/User:Jenia/Translation_Resources where they starting something on a Codex page.

comment:7 in reply to: ↑ 6 @catiakitahara18 months ago

  • Cc contato@… added

Replying to markoheijnen:

Not sure if parent_glossary_id is needed. I guess we could use the project structure for it. So maybe it's a check if sub projects should inherit the glossary.

Check also http://codex.wordpress.org/User:Jenia/Translation_Resources where they starting something on a Codex page.

Just to let you know that the Brazilian and Portuguese Community are developing a Glossary plugin for WordPress. It's already functional and it's on github here: https://github.com/wpbrasil/glossario
I think it would be good if there was some kind of integration between them.

comment:8 @vmassuchetto18 months ago

The README presentation has yet to be translated to English: https://github.com/wpbrasil/glossario/issues/10

We plan to expand the usage of this plugin to other communities, and not only the Brazilian and Portuguese. We're keeping code and issues in English because of that too.

comment:9 @markoheijnen18 months ago

I don't think we should have a integration with that. I think this should be managed from out GlotPress and it's weird that GlotPress should know something about a WordPress installation that installed a specific plugin.

However if it works wel then we could see how we could port it to GlotPress.

comment:10 @vmassuchetto18 months ago

@markoheijnen, I agree.

I don't think it's the case of integrating it. I'm just saying that we noticed the lack of this functionality and started working on some solution.

comment:11 in reply to: ↑ 6 @yoavf18 months ago

Replying to markoheijnen:

Not sure if parent_glossary_id is needed. I guess we could use the project structure for it. So maybe it's a check if sub projects should inherit the glossary.

Make sense - can you think (in the context of WP.org) of glossaries who shouldn't inherit from the parent project glossary?

Replying to vmassuchetto:

I don't think it's the case of integrating it. I'm just saying that we noticed the lack of this functionality and started working on some solution.

I completely understand why you went and created that plugin. The glossary is really a missing feature. Hopefully we'll make some progress on that in the coming months.

comment:12 follow-up: @yoavf17 months ago

Progress update: I have the basics for creating a Glossary, including template and routes. This was the easy part, but I feel more confident now going on and implementing the glossary entry object. Still a lot of work todo for both.

Just noting that the glossary is going to be pretty simple - there will be no revisions or meta data attached to a glossary/glossary entry except for the "last modified" date. I'm considering adding a "created by", "last updated by" fields as well - undecided yet. The glossary will be "view only" by everyone, and editable by validators.

Note that I've already made some (minor) changes to the db schema I posted above, and will post an update once I think I finalized it.

comment:13 in reply to: ↑ 12 ; follow-up: @Nao17 months ago

Replying to yoavf:

I'm considering adding a "created by", "last updated by" fields as well - undecided yet.

I think it would be nice to have these, especially for translation teams that have multiple validators.

I'm assuming the GlotPress Glossary system will be adding PO file import/export functionality. We can maintain portability with the Plugin-based system that way, correct?

comment:14 @yoavf17 months ago

Current tables structures

CREATE TABLE IF NOT EXISTS `gp_glossary_entries` (
  `id` int(10) NOT NULL AUTO_INCREMENT,
  `glossary_id` int(10) NOT NULL,
  `term` varchar(255) NOT NULL,
  `part_of_speech` varchar(255) DEFAULT NULL,
  `comment` text,
  `translation` varchar(255) DEFAULT NULL,
  `date_modified` datetime DEFAULT NULL,
  `last_edited_by` bigint(20) NOT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB  DEFAULT CHARSET=utf8 ;
CREATE TABLE IF NOT EXISTS `gp_glossaries` (
  `id` int(10) NOT NULL AUTO_INCREMENT,
  `translation_set_id` int(10) NOT NULL,
  `parent_glossary_id` int(10) DEFAULT NULL,
  `description` text,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB  DEFAULT CHARSET=utf8  ;

Edit: date_modified should probably be NOT NULL. I'll change that.

Last edited 17 months ago by yoavf (previous) (diff)

@yoavf17 months ago

comment:15 @yoavf17 months ago

97.1.diff is the first public diff for this feature.
It introduces two "things": Glossaries, and Glossary Items, with their routes, and templates.

What works:

  • Creating a glossary - look for the Create Glossary in the translation set header. Will only be shown if you have validator permissions on that translations set. The only thing to set up when creating a glossary is a description for the glossary.
  • Viewing a glosssary. Once you've created it, the create glossary link will be replaced with a link to the actual glossary.
  • Editing a glossary (it's description): clicking the edit link in the glossary header on the glossary view page
  • Adding glossary items
  • Editing glossary items

What needs to be added:

  • Design: everything looks like crap right now.
  • Indication of last editor/last modification date for each glossary item
  • Deleting glossary/glossary items

Other tasks:

  • Testing. I have so far only tested this with either admin permissions, or logged out user. Need to test with other user levels as well.
  • Security review. I probably forgot permissions checks, sanitization, escaping, validation in a few places.
  • Code Tests.
  • Fix all the bugs :-).
Last edited 17 months ago by yoavf (previous) (diff)

comment:16 @ircbot17 months ago

This ticket was mentioned in IRC in #glotpress by yoavf. View the logs.

@yoavf17 months ago

Fix an issue with creating a new glossary in previous patch.

@yoavf17 months ago

@yoavf17 months ago

@yoavf17 months ago

@yoavf17 months ago

comment:17 in reply to: ↑ 13 ; follow-up: @markoheijnen17 months ago

Replying to Nao:

Replying to yoavf:

I'm considering adding a "created by", "last updated by" fields as well - undecided yet.

I think it would be nice to have these, especially for translation teams that have multiple validators.

I'm assuming the GlotPress Glossary system will be adding PO file import/export functionality. We can maintain portability with the Plugin-based system that way, correct?

Personally I wouldn't want to add this. It would mean that on import it may/may not delete values.

comment:18 @markoheijnen17 months ago

yoavf could you explain the gp_glossary_entries table? Like why is part_of_speech needed and the dates.
Will look into the patch tomorrow.

comment:19 in reply to: ↑ 6 @jenia17 months ago

  • Cc jenia@… added

Replying to markoheijnen:

Check also http://codex.wordpress.org/User:Jenia/Translation_Resources where they starting something on a Codex page.

I am going to point that Codex draft to the WordPress.com Translation Resources page instead. The list on WordPress.com is more comprehensive (includes resources for WordPress.com as well as WordPress) and I would rather avoid redundancy by maintaining a single list.

Context: I have been working with a professional translation company to create translation glossaries (and style guides) for 10 languages. The glossaries in particular are following the English/Translation/Part of speech/Description format. Why part of speech? Because of a blog/to blog, an upgrade/to upgrade etc.

comment:20 in reply to: ↑ 17 @Nao17 months ago

  • Cc info@… added

Replying to markoheijnen:

Personally I wouldn't want to add this. It would mean that on import it may/may not delete values.

Not sure which values you're referring to (value = translations?), but I was picturing how GlotPress currently works. On import, new translation overwrites existing ones if changes are found.

That said, import/export is just a nice-to-have feature especially for v1. I think it's ok to omit it for now.

comment:21 @markoheijnen17 months ago

value = an glossary item. This is community maintained and doesn't exists somewhere else. So deleting on import will not happen. Also there will not be an history so there is a change you could overwrite a change.

comment:22 @yoavf17 months ago

I wasn't planning on adding import to v1, but we can look into it later.
For now, I just want something to replace those manually maintained pages everywhere.
Next step is to expose the glossary in the translation interface. Not sure how I'm going to do that yet :).

comment:23 @yoavf17 months ago

Noting here that I'm currently working on inline editing of the glossary. New patch later today, or tomorrow.

Last edited 17 months ago by yoavf (previous) (diff)

@yoavf17 months ago

comment:24 @yoavf17 months ago

97.2.diff adds inline editing of glossary items. The create new glossary item form has been moved to the glossary view. Still needs design work, cleanup and review. Also needs a way to delete a glossary item.

@yoavf17 months ago

comment:25 @yoavf17 months ago

97.4.diff Adds the delete glossary item function.
Also added a bunch of ui improvements, i18n, and cleaned up some code. Still ugly, but everything should be working.

I think the only thing missing for v1 is some display of the last modification info (user/date) on each glossary item.

Last edited 17 months ago by yoavf (previous) (diff)

@yoavf17 months ago

@yoavf17 months ago

@yoavf17 months ago

@yoavf17 months ago

@yoavf17 months ago

comment:26 @yoavf17 months ago

97.5.diff add the updates to the schema file, a basic factory for unit testing the glossary (no tests yet), and some ui improvements over previous patch.

Last edited 17 months ago by yoavf (previous) (diff)

comment:27 follow-up: @markoheijnen17 months ago

I will going to install this today on my site and see how it works.

@yoavf17 months ago

comment:28 in reply to: ↑ 27 @yoavf17 months ago

Replying to markoheijnen:

I will going to install this today on my site and see how it works.

Thanks Marko, looking forward to your feedback.
I've already soft-launched it on WP.com to speed up dev/debugging, and started working on some UI improvements since it's really crude right now.

@yoavf17 months ago

since last patch: ui improvements

comment:29 follow-up: @yoavf17 months ago

If anyone would like to see this in action, take a look at http://translate.wordpress.com/projects/wpcom/fr-ca/default/glossary or http://translate.wordpress.com/projects/wpcom/ja/default/glossary

What I would like to do next is expose the glossary right within the translation set view, something like this:
https://cloudup.com/c3PZVEXWUIt

comment:30 in reply to: ↑ 29 ; follow-up: @jenia17 months ago

Replying to yoavf:

What I would like to do next is expose the glossary right within the translation set view

Translators expect software to highlight glossary terms and translations to them. How about each string is matched against glossary terms (including partial matches in case of verb inclinations, plural nouns etc) and then glossary suggestions are displayed for the strings the translator is looking at?

@jenia17 months ago

How glossary suggestions would look like

comment:31 in reply to: ↑ 30 @yoavf17 months ago

Replying to jenia:

Replying to yoavf:

What I would like to do next is expose the glossary right within the translation set view

Translators expect software to highlight glossary terms and translations to them. How about each string is matched against glossary terms (including partial matches in case of verb inclinations, plural nouns etc) and then glossary suggestions are displayed for the strings the translator is looking at?

If you can mock up the UI for this, I'll be happy to try and implement this. It isn't trivial with how the current translation editor is, so any help would be appreciated.

comment:32 @jenia17 months ago

See above. The key parts are: highlighting the glossary terms within the source string, then outputting the info for the matching terms somewhere not too far.

comment:33 @markoheijnen17 months ago

It should be something that Jenia described but I'm not sure how yet. It would be create if it could highlight the words in the original string but the tricky part is if it should listen to "Part of speech". What is kind of impossible.

comment:34 follow-up: @markoheijnen17 months ago

btw can we move the create/edit glossaries to the translation set? For me that make a bit more sense. Could you also change the database version in /gp-includes/meta.php in the next patch.

Last edited 17 months ago by markoheijnen (previous) (diff)

@markoheijnen17 months ago

Small HTML fixes

comment:35 follow-up: @markoheijnen17 months ago

I fixed some small HTML glitches. Biggest change was moving the classes "action edit" from li to a. This because it happens on other places too. Also change the database version so someone can call /install.php

@yoavf17 months ago

added modified glossary.js

comment:36 in reply to: ↑ 35 @yoavf17 months ago

Replying to markoheijnen:

I fixed some small HTML glitches. Biggest change was moving the classes "action edit" from li to a. This because it happens on other places too. Also change the database version so someone can call /install.php

Thanks! Your patch was missing js/glossary.js, so I added it (after modifying the click selectors to match your changes of li to a).

comment:37 @markoheijnen17 months ago

Crap, I knew I should have used a GUI for it.

comment:38 follow-up: @yoavf17 months ago

Above image is what I'm thinking for the inline glossary. Just need to add the translation comment if any and some general link to the glossary.

A few remaining issues with this:

  • It only matches whole words (i.e. 'comment' but not 'comments'). I can add an exception for words ending with 's' or 'es' but I'm not sure how linguistically complete this is.
  • If a word appears more than once in the glossary (i.e. with a different part of speeche), only one will be shown in the tooltip. I might be able to show all the definitions together with the part of speech - still working on that.

comment:39 @yoavf17 months ago

Here's the bulk of the (in progress) code responsible for the above screenshot:

function map_glossary_entries_to_translations_originals( $translations, $glossary ) {
	$glossary_entries = GP::$glossary_entry->by_glossary_id( $glossary->id );
	$glossary_entries_terms = array();

	foreach ( $glossary_entries as $key => $value ) {
		$glossary_entries_terms[ $key ] = mb_strtolower( $value->term );
	}

	// Longer strings first
	uasort( $glossary_entries_terms, function ($a, $b){ return mb_strlen($a) < mb_strlen($b); } );

	foreach ( $translations as $key => $t ) {
		$translations[$key]->singular_glossary_markup = esc_translation( $t->singular );
		if ( $t->plural ) {
			$translations[$key]->plural_glossary_markup = esc_translation( $t->plural );
		}
		foreach( $glossary_entries_terms as $i => $term ) {
			$glossary_entry = $glossary_entries[ $i ];
			$replacement = '<span class="glossary-word" data-translation="' . esc_js( $glossary_entry->translation ) . '" data-comment="' . esc_attr( $glossary_entry->comment ) . '">$1</span>';
			$translations[$key]->singular_glossary_markup = preg_replace( '/\b(' . $term . ')(?![^<]*<\/span>)/iu', $replacement, $translations[$key]->singular_glossary_markup );
			if ( $t->plural ) {
				$translations[$key]->plural_glossary_markup = preg_replace( '/\b(' . $term . ')(?![^<]*<\/span>)/iu', $replacement, $translations[$key]->plural_glossary_markup );
			}
		}

	}
	return $translations;
}

@yoavf17 months ago

comment:40 in reply to: ↑ 38 ; follow-up: @yoavf17 months ago

Replying to yoavf:

A few remaining issues with this:

  • It only matches whole words (i.e. 'comment' but not 'comments'). I can add an exception for words ending with 's' or 'es' but I'm not sure how linguistically complete this is.
  • If a word appears more than once in the glossary (i.e. with a different part of speeche), only one will be shown in the tooltip. I might be able to show all the definitions together with the part of speech - still working on that.

The latest patch implements both points. I didn't test much, but I really like it. Other than testing, this needs some ui/design tweaks. I also noticed some jittering on the tooltips, that need to be investigated.

@markoheijnen: other than the above, what do you think we need to do to have this committable?


comment:41 in reply to: ↑ 40 ; follow-up: @jenia17 months ago

Replying to yoavf:

  • It only matches whole words (i.e. 'comment' but not 'comments'). I can add an exception for words ending with 's' or 'es' but I'm not sure how linguistically complete this is.

You may get a couple of false positives if you are matching any string containing the glossary terms (does not have to be a full word), e.g. "commenting" and "commenter" and "uncomment" would match "comment", regardless of the part of speech. The benefits of such an approach are worth a couple of false positives, though, since they will give the translator more relevant data.

  • If a word appears more than once in the glossary (i.e. with a different part of speech), only one will be shown in the tooltip. I might be able to show all the definitions together with the part of speech - still working on that.

It would be great to show all the matching terms if there are multiple translations for the same term. Makes life much easier for the translator. Definitions in the tooltip would also be helpful.

comment:42 in reply to: ↑ 41 ; follow-up: @yoavf17 months ago

Replying to jenia:

You may get a couple of false positives if you are matching any string containing the glossary terms (does not have to be a full word), e.g. "commenting" and "commenter" and "uncomment" would match "comment", regardless of the part of speech. The benefits of such an approach are worth a couple of false positives, though, since they will give the translator more relevant data.

The latest patch matches word and word[s] / word[es].
Looks like this:
https://cloudup.com/c9kf9jhlGZG

My hunch is that adding matches for [*]word is probably going to be too general, so I'd rather keep it as is, and we can revisit after the glossary got more usage in the wild.

It would be great to show all the matching terms if there are multiple translations for the same term. Makes life much easier for the translator. Definitions in the tooltip would also be helpful.

That's taken care of in the latest patch :) Still needs to refine the UI, but all the data is there.

comment:43 in reply to: ↑ 42 @jenia17 months ago

Replying to yoavf:

The latest patch matches word and word[s] / word[es].
My hunch is that adding matches for [*]word is probably going to be too general, so I'd rather keep it as is, and we can revisit after the glossary got more usage in the wild.

This covers the nouns pretty well. Verbs won't be surfaced as easily using the "s"/"es" rule. For example, take "follow" - the tooltip should come up not only for "follows", but also "followed" and "following" (all verb forms), probably for "follower" and "followers", and ideally even "unfollow" and "unfollowing".

That's taken care of in the latest patch :)

Great, thanks!

@yoavf17 months ago

Fix for jittery tooltips, and some other minor fixes

@yoavf17 months ago

fixes a small JS issue with the tooltips

@yoavf17 months ago

Prevents warning on translation set view if no glossary exists

@yoavf17 months ago

Fix some permissions issues

@yoavf17 months ago

comment:44 @yoavf17 months ago

  • Keywords has-patch added

latest patch adds a simple import/export feature to glossaries, that supports CSV file with the structure

{term, translation, part of speech, comment}

The first row should be a header row - the 2nd cell being the locale code of the glossary.

All of this is currently live on WP.com. Would love to see it merged and launched on translate.wordpress.org too.

Last edited 17 months ago by yoavf (previous) (diff)

@yoavf17 months ago

bump css/js versions

comment:45 @netweb17 months ago

  • Cc stephen@… added

comment:46 @daveshine17 months ago

  • Cc deckerweb.mobil@… added

comment:47 @markoheijnen17 months ago

I will spent time tomorrow and saturday to get this rolled out then.

@yoavf17 months ago

Add meta information to the glossary entry editing form

comment:48 follow-up: @jenia16 months ago

Love the new meta information - was about to suggest the same.

About the "delete" button, I worry about having a glossary action that is irreversible, in case someone makes a mistake and clicks it by accident. Maybe replace by "deprecate"?

Also for the terms themselves, it would be useful to add "history" like there is one for strings in GlotPress - that is, current "green" versions as well as "deprecated" versions that show which term was used in the past.

comment:49 in reply to: ↑ 48 @yoavf16 months ago

About the "delete" button, I worry about having a glossary action that is irreversible, in case someone makes a mistake and clicks it by accident. Maybe replace by "deprecate"?
Also for the terms themselves, it would be useful to add "history" like there is one for strings in GlotPress - that is, current "green" versions as well as "deprecated" versions that show which term was used in the past.

I see a glossary as something relatively fixed - sure, it may change or be updated here and there, but not too often. As such, I'd rather keep things simple and not add any additional DB columns just so we can deprecate a glossary entry.
In any case, deleting requires three different actions (showing the entry, clicking delete, approving), so I'm not too worried about accidental deletions.

If real life usage of this feature shows that I'm wrong - I'd be happy to revisit this. Nothing is set in stone and we can always change things later. Right now I'd like to freeze this feature (except for any bug fixes of polish, of course). Once it's merged it, we can add feature requests as new tickets.

comment:50 in reply to: ↑ 34 @markoheijnen16 months ago

Replying to markoheijnen:

btw can we move the create/edit glossaries to the translation set? For me that make a bit more sense.

What do you think yoavf?

comment:51 @markoheijnen16 months ago

In 847:

Adds Glossaries. Props yoavf. See #97

comment:52 follow-up: @markoheijnen16 months ago

I just committed the code. I do wonder if the output for GP_Route_Glossary_Entry->glossary_entry_delete_post() can be better. echo json_encode( ''); is a bit weird. Also it's missing unit tests. But the basics is there and from here we can improve it with smaller patches.

comment:53 @markoheijnen16 months ago

#63 was marked as a duplicate.

comment:54 @markoheijnen16 months ago

#142 was marked as a duplicate.

comment:55 @yoavf16 months ago

In 850:

Glossary: No need to expect or send JSON when deleting a glossary entry.

See #97

comment:56 in reply to: ↑ 52 @yoavf16 months ago

Replying to markoheijnen:

echo json_encode( ''); is a bit weird.

Fixed with r850

comment:57 @yoavf16 months ago

In 852:

glossary: remove the indenting from the class properties. There aren't that many of them, and indenting is used for other 'things'.

See #97

comment:58 @markoheijnen16 months ago

I think the indenting is a code standard that WordPress also applies. So even if there aren't many we still should apply it then.

comment:59 @yoavf15 months ago

In 864:

Glossary: add initial unit tests

See #97

comment:60 @yoavf15 months ago

In 865:

glossary entries: add initial tests

See #97

comment:61 @yoavf15 months ago

In 866:

glossary: no need to test reload, since we have no methods that update the glossary directly in our class. props nbachiyski

See #97

comment:62 follow-ups: @waclawjacek15 months ago

  • Cc mail@… added

Is there any chance a glossary could span multiple projects/a project and its subprojects? I could then create a glossary inside WordPress/Polish that would be available in WordPress/Polish/Administration and all the rest.

comment:63 @yoavf15 months ago

In 869:

Glossaries: prevent import of exact duplicates. See #97

comment:64 in reply to: ↑ 62 @yoavf15 months ago

Replying to waclawjacek:

Is there any chance a glossary could span multiple projects/a project and its subprojects? I could then create a glossary inside WordPress/Polish that would be available in WordPress/Polish/Administration and all the rest.

This is in progress - thanks for bringing it up waclawjacek

@yoavf15 months ago

comment:65 in reply to: ↑ 62 @yoavf15 months ago

  • Keywords 2nd-opinion added
  • Priority changed from minor to normal

Replying to waclawjacek:

Is there any chance a glossary could span multiple projects/a project and its subprojects? I could then create a glossary inside WordPress/Polish that would be available in WordPress/Polish/Administration and all the rest.

glossary_hierarchy.diff should take care of that.
If a child project glossary already exists, it will need to be deleted before the parent glossary takes over.

comment:66 @pavelevap15 months ago

  • Cc pavelevap@… added

And what about "Master" Glossary which could be default and available for all projects? There are some frequent words like Post, Category, etc which could be available for all new projects (for example plugins)? New translators would benefit from these tooltips and translations could be standardized through different projects...

comment:67 @markoheijnen14 months ago

In 899:

Remove unused second argument when creating GP_Glossary. See #97

comment:68 @yoavf13 months ago

glossary_hierarchy.2.diff refreshed and updated to work when the immediate parent doesn't actually have sets.

comment:69 @haroonyousuf11 months ago

Importing glossary terms is not working well.
If any character like "á,é,ú,ç,ñ etc." is exist in any translated term in glossary file, simply import process ignores that particular translated word.
You can check out below link where I had tried to import our own glossary in utf-8 csv file format.
https://translate.wordpress.org/projects/wp/dev/rhg/default/glossary
Is there any other way to import terms in glossary? As we have a huge translation terms file and adding manually one by one word to glossary is not a rapid solution. What about the general glossary which should be accessible in all WordPress projects to maintain standard of famous terms like File, Folder, Copy, Paste, Delete etc.

Last edited 11 months ago by haroonyousuf (previous) (diff)

comment:70 @Secretmapper11 months ago

@haroonyousuf Can you try posting the problem csv? I just tried (UTF-8) Glotpréss as a translated word and it seems to import it, so I'm guessing there's a corner case somewhere not getting addressed.

comment:71 @markoheijnen11 months ago

It seems that the fgetcsv() isn't multibyte save. The weird part is that I could download the correct file through export.

Doing import/export again on my installation does not do the same then. It does show some text and then only exports that.

comment:72 @haroonyousuf11 months ago

Just visit below link
http://translate.wordpress.org/projects/wp/dev/rhg/default/glossary
Export glossary file and open it.
For example my first glossary item is "complained". So, you can see the translated term "cékayot goijjé" in exported file but you can't see "cékayot goijjé" at http://translate.wordpress.org/projects/wp/dev/rhg/default/glossary
in Translation column.
It means that it is importing well as I can see all translated words when I export the glossary, but it is not presenting well.
I hope you have understood where is missing something.

comment:73 follow-up: @markoheijnen11 months ago

How did you build your initial import file? Can you upload that.

comment:74 @waclawjacek11 months ago

  • Cc mail@… removed

comment:75 in reply to: ↑ 73 @haroonyousuf11 months ago

Replying to markoheijnen:

How did you build your initial import file? Can you upload that.

I had visited glossary site at http://translate.wordpress.org/projects/wp/dev/rhg/default/glossary
and exported file. Entered the terms with translations and imported back to glossary.

comment:76 @haroonyousuf11 months ago

I am going to upload latest glossary file. Please reset (clear all items) the glossary as it was at the beginning and try to import the file to our glossary. Thank you.

@haroonyousuf11 months ago

Rohingya Glossary

comment:77 @markoheijnen9 months ago

In 959:

Only show description output on glossary page when there is an description. See #97.

comment:78 @markoheijnen9 months ago

In 964:

Add missing ending div to glossary item. See #97

comment:79 @vmassuchetto9 months ago

I'm quite confused: Is the glossary supposed to be a 'per-language' (as the ticket description says) or a 'per-project' solution?

I mean, I can only see the 'create glossary' link on top of each project, but it would be nicer for us in the Brazilian community to have a common glossary for the language.

Considering this is already available on Translate...

comment:80 @markoheijnen8 months ago

In 967:

Fix typo in capability check to show edit link for glossaries. See #97.

comment:81 @netweb7 months ago

In 97-glossary-highlight.png​ above, could we tweak the glossary highlight a little, with a bolder colour and some whitespace between (blank line/padding) between the ------ and the textbox below?

comment:82 @slackbot7 months ago

This ticket was mentioned in Slack in #polyglots by netweb. View the logs.

comment:83 @markoheijnen7 months ago

netweb: I just looked at the styling and will check how the make it more obvious. The whitespace issue is a wp.org issue and unsure how to fix it. Will check when I have my local environment set up for that.

comment:84 @haroonyousuf6 months ago

Hello everyone,

Still waiting for the solution.
Please visit http://translate.wordpress.org/projects/wp/dev/rhg/default/glossary
and export the file. Here you can see the translation in exported file but you can't see the translation on the site.
My imported translation file is attached above.

Regards,

Last edited 6 months ago by haroonyousuf (previous) (diff)

comment:85 @markoheijnen6 months ago

Hey Haroon,

I'm also still waiting for a solution. I played a bit with it but this isn't something I know a lot about and there are also quite a lot of other pressing topics that need to be addressed. I will start making a list on blog.glotpress.org for topics people can look into when they want to help out.

Thanks for the additional files I can test with.

Best, Marko

comment:86 @slackbot6 months ago

This ticket was mentioned in Slack in #polyglots by netweb. View the logs.

comment:87 @hew5 months ago

  • Cc hewsut@… added
Note: See TracTickets for help on using tickets.