text:
Bag tag

Bag tags, also known as baggage tags, baggage checks or luggage tickets, have traditionally been used by bus, train, and airline carriers to route checked luggage to its final destination. The passenger stub is typically handed to the passenger or attached to the ticket envelope:  to aid the passenger in identifying their bag among similar bags at the destination baggage carousel;  as proof—still requested at a few airports—that the passenger is not removing someone else's bag from the baggage reclaim hall; and  as a means for the passenger and carrier to identify and trace a specific bag that has gone astray and was not delivered at the destination. The carriers' liability is restricted to published tariffs and international agreements.

Invention
The first "separable coupon ticket" was patented by John Michael Lyons of Moncton, New Brunswick, on June 5, 1882. The ticket showed the issuing station, the destination, and a consecutive number for reference. The lower half of the ticket was given to the passenger, while the upper half, with a hole at the top, was inserted into a brass sleeve and then attached to the baggage by a strap.

At some point, reinforced paper tags were introduced. These are designed not to detach as easily as older tags during transport.

Warsaw Convention
The Warsaw Convention of 1929, specifically Article Four, established the criteria for issuing a baggage check or luggage ticket. This agreement also established limit of liability on checked baggage.

Previous bag tags
Prior to the 1990s, airline bag tags consisted of a paper tag attached with a string.

The tag contained basic information:

 * Airline/carrier name
 * Flight number
 * Baggage tag number (composed of the two-letter airline code and six digits)
 * Destination airport code

These tags became obsolete because they offered little security and were easy to replicate.

Current bag tags
Current bag tags include a bar code using the Interleaved 2 of 5 symbology. These bag tags are printed using a thermal or barcode printer on an adhesive thermal paper stock. This printed strip is then attached to the luggage at check-in, allowing automated sorting of the bags by bar code readers.

There are two ways that bar code baggage tags are read: hand held scanners, and in-line arrays. In-line arrays are built into the baggage conveyor system and use a 360-degree array of lasers or cameras to read the bar code tags from multiple angles because baggage and the orientation of the bar code tag can shift as the bag travels through the conveyor belt system. Camera systems are replacing lasers due to their greater ability to read damaged or folded tags.

One of the limitations of this system is that in order to read bar codes from the bottom of the belt, laser or camera arrays are placed below the gap between two sections of conveyor belt. Due to the frequent build-up of debris and dust on these lower arrays, the rate of successful reads can be low, although the camera systems improve the likelihood of reading tags from this position because of the algorithms used in their software.

Frequently, the "read rate", the percentage of bar code tags successfully read by these arrays, can be as low as 85%. This means that more than one out of ten bar code baggage tags are not successfully read, and these bags are shunted off for manual reading, resulting in extra labor and delay. Systems employing cameras typically have better read rates than those using lasers - up to 99.5% in ideal conditions.

For flights departing from an international airport within the European Union, bag tags are issued with green edges. Passengers are eligible to take these bags through a separate "Blue Channel" (or alternatively the "Green Channel" = "nothing to declare") at Customs if arriving at another EU airport.

Bar codes cannot be automatically scanned without direct sight and undamaged print. Because of reading problems with poorly printed, obscured, crumpled, scored or otherwise damaged bar codes, some airlines have started using radio-frequency identification (RFID) chips embedded in the tags.

In the US, McCarran International Airport has installed an RFID system throughout the airport. Hong Kong International Airport has also installed an RFID system. The International Air Transport Association (IATA) is working to standardize RFID bag tags.

British Airways is currently conducting a trial to test re-usable electronic luggage tags featuring electronic paper technology. The passenger checks in using the British Airways smartphone app, then holds the smartphone close to the tag. The flight details and barcode are transmitted to the tag using NFC technology. Because the tag utilises electronic paper, the battery need only power the tag during the transmission of data.

Fast Travel Global Ltd has developed a re-usable electronic luggage tag product called the eTag. This is also electronic paper-based but is not limited to a single airline. The passenger will check in using a supported airline's smartphone app and send the relevant flight information to the tag via Bluetooth Low Energy.

Qantas introduced Q Bag Tags in 2011. Unlike the British Airways tags, they do not feature a screen, which means there is no barcode to scan. This has limited the use of the tags to domestic flights within Australia on the Qantas network. The tags were initially given free of charge to members of the Qantas Frequent Flyer program with Silver, Gold or Platinum status. The tags can also be purchased for A$29.95.

Over the last years, there have been numerous of initiatives to develop electronic bag tags, by both independent technology companies as well as some airlines. The main benefits of electronic bag tags include self-control and ease-of-use by passengers, time-saving by skipping queues at the airport, improved read rates compared to printed bag tags and, as electronic bag tags are adopted, significant operational cost reduction for the airlines.

The first company to successfully launch has been Rimowa in a partnership with Lufthansa in March, 2016. The concept of electronic bag tags has been gaining ground following that launch. On January 9, 2018, Lufthansa introduced a new electronic bag tag to their passengers, BAGTAG. BAGTAG is the first fully secure operational electronic bag tag that can be attached to any suitcase and has integrated radio-frequency identification technology.

Identification
The first automated baggage sorting systems were developed in the 1980s by Eastern Air Lines at their Miami International Airport hub. Other airlines soon followed with their own systems, including United Air Lines, TWA, Delta, and American Airlines. None of these systems were interchangeable. In some systems, the bar code was used to represent a three-letter destination airport code, and in others it was a two-digit sorting symbol instructing the system at which pier to deliver the bag.

As a result of the bombing of Air India Flight 182 on June 23, 1985, the airline industry, led by IATA, convened the Baggage Security Working Group (BSWG) to change international standards and require passenger baggage reconciliation. The Chairman of the BSWG, John Vermilye of Eastern Airlines, proposed that the industry adopt the already-proven license plate system.

This concept used a barcode to represent the baggage tag number. At check-in, this number was associated with the passenger details, including flight number, destination, connection information, and even class of service to indicate priority handling.

Working with Allen Davidson of Litton Industries, with whom Eastern had developed the license plate concept, the BSWG adopted this system as the common industry standard for passenger baggage reconciliation. Initially the barcode, or license plate, was used to match baggage with passengers, ensuring that only the baggage of passengers who had actually boarded the flight were carried onto the aircraft. This standard was adopted by IATA Resolution in 1987.

By 1989, the license plate concept was expanded to become the industry standard for automated baggage sorting as well. The barcodes were enlarged to facilitate automated reading. The barcode was shown in two different orientations or in a "T" shape, called the "orthogonal" representation.

The term license plate is the official term used by the IATA, the airlines, and the airports for the ten-digit numeric code on a bag tag issued by a carrier or handling agent at check-in. The license plate is printed on the carrier tag in barcode form and in human-readable form (as defined in Resolution 740 in the IATA Passenger Services Conference Resolutions Manual, published annually by IATA).

The license plate is the index number linking the Baggage Source Message (BSM), sent by a carrier's departure control system, to the airport's baggage handling system. This message (BSM) contains the flight details and passenger information. Each digit in the license plate has a specific meaning. The automated baggage handling system scans the barcodes on the carrier tags and sorts the bags accordingly. Both the license plate number and the BSM are essential for automated sorting of baggage.

The human-readable license plate will have either a two-character or a three-digit IATA carrier code. For example, it may be either "BA728359" or "0125728359." "BA" would be the two-character IATA code for British Airways), and "125" would be the three-digit IATA carrier code. Nevertheless, the barcode will always be the full ten digits.

The first digit in the ten-digit license plate is not part of the carrier code. It can be in the range of zero to nine.

Zero is for interline or online tags, one is for fallback tags, and two is for "rush" tags.

Fallback tags are pre-printed or demand-printed tags for use only by the airport's baggage handling system. These tags are used when there is a problem in communication between the carrier's departure control system and the airport's baggage handling system (as defined in IATA Recommended Practice 1740b).

A "rush" bag is a bag that missed its original flight (now technically a lost luggage to be transported to be united to its owner) and is now flying unaccompanied.

The purpose of numbers in the range of three to nine is not defined by the IATA, but they can be used by each carrier for their own specific needs. The first digit is commonly used as a million indicator for the normal six-digit tag number.

Besides the license plate number, the tag also has:

 * Name of Airport of Arrival
 * Departure Time
 * IATA airport code of Airport of Arrival
 * Airline Code and Flight Number
 * Name of Passenger Identified with the Baggage (Last Name, First Name)

title: Bag tag


text: Template:Nihongo

license: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/4.0/

title: Template:Nihongo


text:
The Clock Maker

The Clock Maker is an American comic book published by Image Comics starting in January 2003. The comic was written by Jim Krueger and pencilled by Matt Smith (Act I) and Jason Baroody (Act II).

The title was launched during a new superhero comics initiative at Image. The story is about a giant clockworks hidden within a hollow mountain in Switzerland. Hundreds of men that never age maintain the old behemoth's operation. The clock is the cause and sustainer of the Earth's revolutions—and more, it is the gateway to Heaven itself.

The first four issues were published as double-sized editions with a 1:1 reproduction ratio, meaning the original art was not resized when it was published. The books were folded in half to fit on standard news racks, and in the current sized protective polymer bags. The back cover of the fourth issue advertised a fifth, coming in June 2003, however that issue was never published.

Act II was never printed in the serial format, but only as a 48-page graphic novel (ISBN 1-58240-377-5) in 2004. Act three was intended to be published in the same manner, but, to this date, has never surfaced. Krueger maintains that the book will be out “in the near future” and that a collection will also be forthcoming.

Creators

 * Inker: Michael Halbleib
 * Letterer: John D. Roberts
 * Colorist: Brett Weldele

title: The Clock Maker


text:
Geelong Advertiser

The Geelong Advertiser is a daily newspaper circulating in Geelong, Victoria, Australia, the Bellarine Peninsula, and surrounding areas. First published on 21 November 1840, the Geelong Advertiser is the oldest newspaper title in Victoria and the second-oldest in Australia. The newspaper is currently owned by News Corp. It was the Pacific Area Newspaper Publishers Association 2009 Newspaper of the Year (circulation 25,000 to 90,000).

History
The Geelong Advertiser was initially edited by James Harrison, a Scottish emigrant, who had arrived in Sydney in 1837 to set up a printing press for the English company Tegg & Co.

Moving to Melbourne in 1839, he found employment with John Pascoe Fawkner, as a compositor, and later editor, of Fawkner's Port Phillip Patriot. When Fawkner acquired a new press, Harrison offered him £30 for the original press, and started Geelong's first newspaper. The first edition of the Geelong Advertiser, which originally appeared weekly, was published on Saturday 21 November 1840, edited by 'James Harrison and printed and published for John Pascoe Fawkner (sole proprietor) by William Watkins...'

Its first editorial offered the following doggerel:

"Bring forth the press! When first that mighty shout was heard. Truth rose in radiant light ensphered. The Nations to address."

By November 1842 Harrison had become the sole owner of the paper. For the first seven years it was printed in demi-folio size before changing to broadsheet. In 1858 the newspaper retired the original wooden press, adopted new typography, and was printed by a mechanised steam press.

From 1845 to 1847, the newspaper was named the 'Geelong Advertiser, and Squatters Advocate'. The first edition under this title published on 28 May 1845.

The newspaper did not feature news on the front page until 21 June 1924, coinciding with the inauguration of a new printing press. Before that time the front page was devoted to classified advertising. Trials of a tabloid-sized paper were made in 2000, when a Sunday edition was printed for the Sydney 2000 Olympic Games. The large broadsheet paper size was used until 2001, when the newspaper changed to the tabloid format which has been used since.

title: Geelong Advertiser


text:
William Andrews

William or Willie Andrews may refer to:

Politics and law

 * William Drennan Andrews (1832–1924), Irish judge
 * William Henry Andrews (1846–1919), American politician
 * William E. Andrews (1854–1942), U.S. Congressman from Nebraska
 * William Shankland Andrews (1858–1936), American lawyer, judge, and politician
 * William L. Andrews (1865–1936), American politician in the Virginia Senate
 * William H. Andrews (unionist) (1870–1950), English politician in South Africa
 * William Noble Andrews (1876–1937), U.S. Congressman from Maryland
 * William T. Andrews (1898–1984), American politician in the New York State Assembly
 * William C. Andrews (1934–2021), American politician in the Florida House of Representatives
 * William F. Andrews (politician) (born 1946), American politician in the Florida House of Representatives
 * William Andrews III (born 1952), American politician in the Mississippi House of Representatives

Religion

 * William Andrews (priest) (fl. 1702–1736), Irish Anglican priest and educationalist
 * William Eusebius Andrews (1773–1837), English religious journalist
 * William Watson Andrews (1810–1897), American clergyman of the Catholic Apostolic Church
 * William Buckton Andrews (1829–1918), Anglican clergyman in South Australia, a.k.a. "Canon Andrews"

Science and medicine

 * William Andrews (naturalist) (1802–1880), English naturalist
 * William Symes Andrews (1847–1929), English electrical engineer
 * William H. Andrews (biologist) (born 1951), American telomere biologist

Sports

 * Curley Andrews (William Andrews, fl. 1940s), American baseball player
 * William Andrews (American football) (born 1955), American football player
 * Willie Andrews (born 1983), American football player

Others

 * William Andrews (astrologer) (fl. 1656–1683), astrologer
 * William Andrews (factory manager) (1835–1914), English diarist and factory manager for Cash's of Coventry
 * William Andrews (Australian actor) (1836–1878), Australian stage actor and comedian
 * William F. Andrews (businessman) (born c. 1933), American businessman
 * William L. Andrews (academic) (born 1946), American academic
 * William Andrews (comedian) (born 1977), British actor and comedian
 * William C. Andrews (art director) (1901–1986), British film set designer

title: William Andrews


text:
User talk:Bornok 20

Welcome!

Hello, and welcome to Wikipedia! Thank you for your contributions. I hope you like the place and decide to stay. Here are a few good links for newcomers: I hope you enjoy editing here and being a Wikipedian! Please sign your name on talk pages using four tildes (~~); this will automatically produce your name and the date. If you have any questions, check out Where to ask a question or ask me on my talk page. Again, welcome! Coffee 07:11, 9 October 2005 (UTC)
 * The five pillars of Wikipedia
 * How to edit a page
 * Help pages
 * Tutorial
 * How to write a great article
 * Manual of Style

Barangays
Personally, I do not think that every barangay is notable enough to warrant an article, and we should treat them on a case to case basis as we do with people... there are more than 40,000 barangays. In a lot of cases I think the information about the barangay could be merged into the city/municipality article.

Hmm... if you are actually planning to make articles for a lot of Barugo barangays, I suppose we could keep the template. But let's not get carried away and make templates filled with red links for all 1617 cities and municipalities. :) Also, try to avoid blank sections unless you plan to fill them up. Thanks.. Coffee 11:56, 9 October 2005 (UTC)

 * The articles you started named "X, Barugo, Leyte" are being deleted because they are empty. In the future, please be sure you have enough information about a topic to warrant an encyclopedia article before creating it. Many people write first offline (for example, on Microsoft Word or the like) and then create the article by pasting the text in. Alternatively, you can start a user subpage along the lines of User:Bornok 20/X, Barugo, Leyte where you can work on your article before moving it into the main article space. --Angr/undefined 21:11, 12 October 2005 (UTC)

Re: Chronology of important events in Pinoy Big Brother (season 2)
I didn't include the "smart card task" because it isn't important. And the housemates who were fainted, there were none; they were just taken to the hospital for checking since the doctor could not make it to the House. - 上村七美 | talk 10:49, 28 June 2007 (UTC)

Re: Butuan
Apparently, when Butuan became a highly-urbanized city, it became independent of Agusan del Norte. Thus, Butuan is no longer entitled to a part of the internal revenue allotment assigned to Agusan del Norte, but gets its budget direct from the national gov't. Also, city residents do not vote for provincial officials (governor, vice governor, provincial board members). But, Butuan City is still part of the 1st District of Agusan del Norte, which is only concerned with representation in the House of Representatives and is in no way associated with the local government units, so there's no contradiction there. It's actually all very confusing since there are many statuses of cities in the Philippines and their relationships with their mother provinces are done on a case-to-case basis. You might want to talk to Scorpion prinz since he is more knowledgeable about the cities vis-a-vis the Local Government Code of 1991.

But here's a short history of Butuan's status:

 * Is a municipality of Agusan province until 1950
 * Became a city of Agusan province (and can vote for provincial officials) in 1950 (R.A. 523)
 * Agusan was split into Agusan del Norte and Agusan del Sur in 1967; Butuan became capital of Agusan del Norte (R.A. 4979)
 * Certified as a highly-urbanized city in 1985 (I assume that they lost their provincial voting powers because of this)
 * Became part of the 1st District of Agusan del Norte (1987 Constitution)
 * No longer capital of Agusan del Norte in 2000 (R.A. 8811)

--seav 04:38, 24 October 2007 (UTC)

May 2009
Welcome to Wikipedia. The recent edit you made to the page Barugo, Leyte has been reverted, as it appears to be unconstructive. Use the sandbox for testing; if you believe the edit was constructive, please ensure that you provide an informative edit summary. You may also wish to read the introduction to editing. Thank you. X clamation point  03:19, 2 May 2009 (UTC)

Speedy deletion of Local Executives of Barugo (Past to Present)
A tag has been placed on Local Executives of Barugo (Past to Present) requesting that it be speedily deleted from Wikipedia. This has been done under section A7 of the criteria for speedy deletion, because the article appears to be about about a person, organization (band, club, company, etc.) or web content, but it does not indicate how or why the subject is important or significant: that is, why an article about that subject should be included in an encyclopedia. Under the criteria for speedy deletion, such articles may be deleted at any time. Please see the guidelines for what is generally accepted as notable

If you think that this notice was placed here in error, you may contest the deletion by adding  to the top of the page that has been nominated for deletion (just below the existing speedy deletion or "db" tag), coupled with adding a note on the talk page explaining your position, but be aware that once tagged for speedy deletion, if the page meets the criterion it may be deleted without delay. Please do not remove the speedy deletion tag yourself, but don't hesitate to add information to the page that would render it more in conformance with Wikipedia's policies and guidelines. Lastly, please note that if the page does get deleted, you can contact one of these admins to request that they userfy the page or have a copy emailed to you. mhking (talk) 04:23, 2 May 2009 (UTC)

Speedy deletion nomination of Elected Officials of the Local Government of Barugo for Years 2007-2010

Hello, and welcome to Wikipedia. This is a notice to inform you that a tag has been placed on Elected Officials of the Local Government of Barugo for Years 2007-2010 requesting that it be speedily deleted from Wikipedia. This has been done under section A3 of the criteria for speedy deletion, because it is an article with no content whatsoever, or whose contents consist only of external links, a "See also" section, book references, category tags, template tags, interwiki links, a rephrasing of the title, or an attempt to contact the subject of the article. Please see Wikipedia:Stub for our minimum information standards for short articles. Also please note that articles must be on notable subjects and should provide references to reliable sources that verify their content.

If you think that the page was nominated in error, contest the nomination by clicking on the button labelled "Click here to contest this speedy deletion" in the speedy deletion tag. Doing so will take you to the talk page where you can explain why you believe the page should not be deleted. You can also visit the page's talk page directly to give your reasons, but be aware that once a page is tagged for speedy deletion, it may be removed without delay. Please do not remove the speedy deletion tag yourself, but do not hesitate to add information that is consistent with Wikipedia's policies and guidelines. If the page is deleted, you can contact one of these administrators to request that the administrator userfy the page or email a copy to you. – H T  D  04:46, 30 December 2012 (UTC)

Elected Officials of the Local Government of Barugo for Years 2007-2010 listed at Redirects for discussion
An editor has asked for a discussion to address the redirect Elected Officials of the Local Government of Barugo for Years 2007-2010. Since you had some involvement with the Elected Officials of the Local Government of Barugo for Years 2007-2010 redirect, you might want to participate in the redirect discussion (if you have not already done so). – H T  D  12:01, 30 December 2012 (UTC)

title: User talk:Bornok 20


text:
Gustavo López (footballer, born 1973)

Gustavo Adrián López Pablo (born 13 April 1973) is an Argentine football coach and former player who played as a left winger. He is an assistant coach for Atlético Madrid.

He spent the vast majority of his professional career in Spain, amassing La Liga totals of 310 matches and 33 goals during 11 seasons (13 in the country overall), playing for Zaragoza and Celta. He started his career with Independiente.

An Argentine international for nine years, López represented the nation at the 2002 World Cup and two Copa América tournaments.

Early years and Zaragoza
Born in Valentín Alsina, Buenos Aires, López began his career with local Club Atlético Independiente in 1991. He won four major titles during his spell there, all arriving in his last years.

In January 1996, López moved to Spain with Real Zaragoza for a club record 420 million pesetas, making his La Liga debut on the 7th in a 1–1 home draw against Rayo Vallecano. He scored five goals in 32 matches in his third full season, helping to the ninth position in the table; during most of his stint in Aragon, he partnered countryman Kily González.

Celta
López rejoined former Zaragoza manager Víctor Fernández at Celta de Vigo in summer 1999, and quickly became an essential first-team unit. He netted twice in five appearances in the 2000–01 edition of the Copa del Rey, helping the side to the final against his former club (1–3 loss in Seville), then contributed with 33 games (29 starts, 2.232 minutes of action) in the 2002–03 campaign as the Galicians finished fourth and qualified for the UEFA Champions League for the first time in their history.

At the end of 2006–07, after having suffered his second relegation with Celta and having already renewed his contract twice by reducing his wages, 34-year-old López decided to leave the club, amassing official totals of 292 matches and 29 goals. He retired at the end of the following season, also dropping down a level with Cádiz CF in Segunda División, then worked as commentator for Canal+ on their coverage of La Liga and for PRISA regarding the Argentine top level, as well as running training camps for children.

International career
López won 32 caps for Argentina and scored four goals, making his debut against Romania in December 1994. He represented the country at the 1997 and 1999 Copa América tournaments, being an unused squad member at the ill-fated 2002 FIFA World Cup in Japan and South Korea.

Additionally, López helped the under-23 side win the silver medal at the 1996 Summer Olympics in Atlanta, scoring in the 3–1 group stage win over the United States.

Managerial career
On June 15, 2022, López joined Diego Simeone's coaching staff in Atlético Madrid.

Honours
Independiente
 * Argentine Primera División: Clausura 1994
 * Supercopa Sudamericana: 1994, 1995
 * Recopa Sudamericana: 1995

Celta
 * UEFA Intertoto Cup: 2000
 * Copa del Rey: Runner-up 2000–01

Argentina
 * Summer Olympic Games: Silver medal 1996

title: Gustavo López (footballer, born 1973)


text:
Madonna di Loreto

Madonna di Loreto may refer to:

 * Our Lady of Loreto, the title of the Virgin Mary with respect to the Holy House of Loreto and the image displayed there
 * Madonna di Loreto (Caravaggio), a c. 1604–1606 painting
 * Madonna of Loreto, a c. 1511 painting by Raphael
 * Madonna of Loreto (Perugino), a c 1507 painting

title: Madonna di Loreto


text: User talk:70.226.207.222

title: User talk:70.226.207.222


text:
List of colleges in Haiti

This is a list of colleges in Haiti.

Colleges
This is a list of colleges in Haiti. • Collège Catts Pressoir

• Collège de Mazenod

• College Harry Brakeman

• Collège Marie-Anne

• Collège Mixte de l'Experience, in Marin (just north of the Port-au-Prince airport)

• Collège Mixte Philadelphie – Dantès Bellegarde

• Collège Notre-Dame

• Collège Roger Anglade

• College Saint-Louis de Bourdon

• Collège Suisse, Jacmel

• College Susan Schuenke

• Collège Universitaire Caraïbe

• École Saint Thomas d'Aquin, Port-au-Prince

• Collège Chrétien d'Haïti

• Institution Saint Louis de Gonzague

• Institution du Sacré Cœur

• Collège Frère Odile Joseph (FIC) aux Cayes, should in the list of college back there.

• Collège Saint Dominique Cayes Haiti

• Séminaire de Théologie Evangélique de Port-au-Prince (STEP)

title: List of colleges in Haiti


text: User talk:62.38.174.251

title: User talk:62.38.174.251


text:
Jessica Rakoczy

Jessica Rakoczy (born April 14, 1977) is a professional boxer and professional mixed martial arts fighter from Hamilton, Ontario, and seven time women lightweight boxing champion of the world.

Boxing career
Rakoczy made her professional boxing debut in October 2000. She has earned a record of 33 wins against 3 losses, with one no contest.

She is as a 3 time WIBA World Champion and 2 time former WBC Lightweight Champion. Most recently, she won the vacant WIBA Women's International Boxing Association super bantamweight title with a win against Ada Vélez on January 24, 2013.

Early career
Rakoczy made her professional MMA debut in October 2009. In five fights, she amassed a record of 1 win, 3 losses and one no contest.

The Ultimate Fighter
In August 2013, it was announced that Rakoczy was one of the fighters selected to be on The Ultimate Fighter: Team Rousey vs. Team Tate.

Rakoczy faced Revelina Berto in the elimination fight to get into the house. Despite both women being boxers, the majority of the fight was contested on the ground, where Rakoczy won via an armbar submission in the second round.

During her first tournament fight in the house, Rakoczy faced veteran Roxanne Modafferi. After losing the first round with it mostly being contested on the ground and struggling for takedowns, Rakoczy landed multiple punches on the feet in the second round. After several heavy blows landed and a slam against Modafferi's armbar attempt Rakoczy won via TKO.

In the semifinals, Rakoczy faced Raquel Pennington and won the fight via unanimous decision after three rounds.

Ultimate Fighting Championship
Rakoczy faced Julianna Peña in the finals on November 30, 2013, at The Ultimate Fighter 18 Finale. She lost the bout via TKO in the final seconds of the first round.

Rakoczy made her return to the UFC Octagon on April 25, 2015, in her strawweight debut against Valérie Létourneau at UFC 186 in Montreal, Quebec on April 25, 2015. She lost the fight via unanimous decision and was subsequently released from the UFC.

Boxing

 * International Boxing Association
 * IBA Women's Lightweight Championship (1 time)

 * North American Boxing Association
 * NABA Women's Lightweight Championship (1 time)

 * North American Boxing Federation
 * NABF Female Lightweight Championship (1 time)

 * Women's International Boxing Association
 * WIBA Intercontinental Lightweight Championship (1 time)

 * World Boxing Council
 * WBC Female World Lightweight Championship (2 times)

Mixed martial arts

 * Ultimate Fighting Championship
 * The Ultimate Fighter 18 Tournament Runner-Up
 * The Ultimate Fighter 18 Knockout of the Season

Professional boxing record

 * style="text-align:center;" colspan="8"|33 Wins (12 knockouts, 21 decisions), 3 Losses (1 knockout, 2 decisions), 0 Draws, 1 No Contest
 * - style="text-align:center; background:#e3e3e3;"
 * style="border-style:none none solid solid; "|Res.
 * style="border-style:none none solid solid; "|Record
 * style="border-style:none none solid solid; "|Opponent
 * style="border-style:none none solid solid; "|Type
 * style="border-style:none none solid solid; "|Rd., Time
 * style="border-style:none none solid solid; "|Date
 * style="border-style:none none solid solid; "|Location
 * style="border-style:none none solid solid; "|Notes
 * - align=center
 * Win
 * 33–3 (1)
 * align=left|🇵🇷 Ada Vélez
 * UD||(10)
 * 2013-01-24
 * align=left|🇺🇸 Coca-Cola Center, Oklahoma City, Oklahoma
 * align=left|Won the vacant WIBA Super Bantamweight Title.
 * - align=center
 * Win
 * 32–3 (1)
 * align=left|🇺🇸 Brittany Cruz
 * TKO||4 (8)
 * 2012-05-04
 * align=left|🇺🇸 Hard Rock Hotel and Casino, Las Vegas, Nevada
 * align=left|
 * - align=center
 * Win
 * 31–3 (1)
 * align=left|🇺🇸 Jessica Mohs
 * TKO||3 (6)
 * 2009-07-16
 * align=left|🇺🇸 Tachi Palace Hotel & Casino, Lemoore, California
 * align=left|
 * - align=center
 * Win
 * 30–3 (1)
 * align=left|🇵🇷 Belinda Laracuente
 * UD||(6)
 * 2009-04-23
 * align=left|🇺🇸 Tachi Palace Hotel & Casino, Lemoore, California
 * align=left|
 * - align=center
 * Win
 * 29–3 (1)
 * align=left|🇵🇷 Cindy Serrano
 * UD||(8)
 * 2008-04-17
 * align=left|🇺🇸 Tachi Palace Hotel & Casino, Lemoore, California
 * align=left|
 * - align=center
 * Win
 * 28–3 (1)
 * align=left|🇵🇷 Belinda Laracuente
 * UD||(10)
 * 2008-02-29
 * align=left|🇺🇸 Tachi Palace Hotel & Casino, Lemoore, California
 * align=left|Defended the NABF Female Lightweight Title.
 * - align=center
 * Loss
 * 27–3 (1)
 * align=left|🇺🇸 Ann Saccurato
 * KO||10 (10)
 * 2007-09-27
 * align=left|🇺🇸 Tachi Palace Hotel & Casino, Lemoore, California
 * align=left|Lost the WBC Female Lightweight Title.
 * - align=center
 * Win
 * 27–2 (1)
 * align=left|🇺🇸 Terri Blair
 * UD||(8)
 * 2007-05-17
 * align=left|🇺🇸 Tachi Palace Hotel & Casino, Lemoore, California
 * align=left|
 * - align=center
 * Win
 * 26–2 (1)
 * align=left|🇺🇸 Kelli Cofer
 * TD||5 (10)
 * 2007-02-22
 * align=left|🇺🇸 Tachi Palace Hotel & Casino, Lemoore, California
 * align=left|Cofer suffered a cut eye from an accidental headbutt. Won the vacant WBC Female Lightweight Title.
 * - align=center
 * Win
 * 25–2 (1)
 * align=left|🇺🇸 Jessica Mohs
 * TKO||2 (6)
 * 2007-01-05
 * align=left|🇺🇸 DeSoto Civic Center, Southaven, Mississippi
 * align=left|
 * - align=center
 * Win
 * 24–2 (1)
 * align=left|🇺🇸 Tawnyah Freeman
 * TKO||1 (8)
 * 2006-12-14
 * align=left|🇺🇸 Tachi Palace Hotel & Casino, Lemoore, California
 * align=left|Won vacant NABF Female Lightweight Title.
 * - align=center
 * NC
 * 23–2 (1)
 * align=left|🇵🇷 Belinda Laracuente
 * NC||3 (6)
 * 2006-09-02
 * align=left|🇺🇸 Staples Center, Los Angeles, California
 * align=left|Fight stopped after Rakoczy was cut from an accidental headbutt.
 * - align=center
 * Win
 * 23–2
 * align=left|🇺🇸 Angel McNamara
 * TKO||5 (6)
 * 2006-04-12
 * align=left|🇺🇸 Tachi Palace Hotel & Casino, Lemoore, California
 * align=left|Won vacant WIBA Title.
 * - align=center
 * Win
 * 22–2
 * align=left|🇺🇸 Terri Blair
 * UD||(8)
 * 2006-02-23
 * align=left|🇺🇸 Tachi Palace Hotel & Casino, Lemoore, California
 * align=left|
 * - align=center
 * Win
 * 21–2
 * align=left|🇺🇸 Angel McNamara
 * UD||(6)
 * 2005-12-02
 * align=left|🇺🇸 Tachi Palace Hotel & Casino, Lemoore, California
 * align=left|
 * - align=center
 * Loss
 * 20–2
 * align=left|🇺🇸 Eliza Olson
 * UD||(10)
 * 2005-09-16
 * align=left|🇺🇸 Palace Indian Gaming Center, Lemoore, California
 * align=left|Lost the IBA Female Lightweight Title & WBC Female Lightweight Title.
 * - align=center
 * Win
 * 20–1
 * align=left|🏴 Jane Couch
 * TKO||6 (10)
 * 2005-07-21
 * align=left|🇺🇸 Palace Indian Gaming Center, Lemoore, California
 * align=left|Defended the IBA Female Lightweight Title & won vacant WBC Female Lightweight Title.
 * - align=center
 * Win
 * 19–1
 * align=left|🇵🇷 Belinda Laracuente
 * UD||(10)
 * 2005-04-01
 * align=left|🇺🇸 Palace Indian Gaming Center, Lemoore, California
 * align=left|Defended the IBA Female Lightweight Title & won vacant NABA Female Lightweight Title.
 * - align=center
 * Win
 * 18–1
 * align=left|🇺🇸 Mia St. John
 * TKO||2 (6)
 * 2005-02-10
 * align=left|🇺🇸 Palace Indian Gaming Center, Lemoore, California
 * align=left|
 * - align=center
 * Win
 * 17–1
 * align=left|🇺🇸 Dana Kendrick
 * TKO||1 (8)
 * 2004-12-16
 * align=left|🇺🇸 Palace Indian Gaming Center, Lemoore, California
 * align=left|
 * - align=center
 * Win
 * 16–1
 * align=left|🇨🇦 Olivia Gerula
 * UD||(8)
 * 2004-07-01
 * align=left|🇺🇸 Palace Indian Gaming Center, Lemoore, California
 * align=left|
 * - align=center
 * Win
 * 15–1
 * align=left|🇺🇸 Gloria Ramirez
 * UD||(8)
 * 2004-05-22
 * align=left|🇺🇸 Warner Theatre, Fresno, California
 * align=left|
 * - align=center
 * Win
 * 14–1
 * align=left|🇺🇸 Mia St. John
 * UD||(8)
 * 2004-04-15
 * align=left|🇺🇸 Palace Indian Gaming Center, Lemoore, California
 * align=left|
 * - align=center
 * Win
 * 13–1
 * align=left|🇺🇸 Lisa Lewis
 * UD||(10)
 * 2004-02-19
 * align=left|🇺🇸 Palace Indian Gaming Center, Lemoore, California
 * align=left|Won vacant IBA Female Lightweight Title.
 * - align=center
 * Loss
 * 12–1
 * align=left|🇺🇸 Jenifer Alcorn
 * SD||(10)
 * 2003-01-17
 * align=left|🇺🇸 Palace Indian Gaming Center, Lemoore, California
 * align=left|For vacant IWBF Lightweight Title.
 * - align=center
 * Win
 * 12–0
 * align=left|🇺🇸 Cheryl Nance
 * KO||4 (6)
 * 2002-11-22
 * align=left|🇺🇸 Palace Indian Gaming Center, Lemoore, California
 * align=left|
 * - align=center
 * Win
 * 11–0
 * align=left|🇺🇸 Gail Muzzey
 * TKO||1 (6)
 * 2002-07-09
 * align=left|🇺🇸 Playboy Mansion, Beverly Hills, California
 * align=left|
 * - align=center
 * Win
 * 10–0
 * align=left|🇺🇸 Gloria Ramirez
 * UD||(6)
 * 2002-02-17
 * align=left|🇺🇸 Stardust Hotel & Casino, Bernalillo, New Mexico
 * align=left|
 * - align=center
 * Win
 * 9–0
 * align=left|🇺🇸 Layla McCarter
 * UD||(6)
 * 2002-02-17
 * align=left|🇺🇸 Stardust Hotel & Casino, Las Vegas, Nevada
 * align=left|
 * - align=center
 * Win
 * 8–0
 * align=left|🇺🇸 Michelle Linden
 * UD||(6)
 * 2001-11-09
 * align=left|🇺🇸 Spa Resort Casino, Palm Springs, California
 * align=left|
 * - align=center
 * Win
 * 7–0
 * align=left|🇺🇸 Mikee Stafford
 * UD||(6)
 * 2001-08-18
 * align=left|🇺🇸 Cox Pavilion, Las Vegas, Nevada
 * align=left|
 * - align=center
 * Win
 * 6–0
 * align=left|🇲🇽 Imelda Arias
 * UD||(4)
 * 2001-07-08
 * align=left|🇺🇸 Texas Station Casino, Las Vegas, Nevada
 * align=left|
 * - align=center
 * Win
 * 5–0
 * align=left|🇺🇸 Vicky Clardy
 * UD||(6)
 * 2001-05-20
 * align=left|🇺🇸 Belterra Casino Resort, Elizabeth, Indiana
 * align=left|
 * - align=center
 * Win
 * 4–0
 * align=left|🇺🇸 Mikee Stafford
 * UD||(6)
 * 2001-04-01
 * align=left|🇺🇸 Hard Rock Hotel and Casino, Las Vegas, Nevada
 * align=left|
 * - align=center
 * Win
 * 3–0
 * align=left|🇺🇸 Mary Wells
 * UD||(4)
 * 2001-01-21
 * align=left|🇺🇸 Sunset Station, San Antonio, Texas
 * align=left|
 * - align=center
 * Win
 * 2–0
 * align=left|🇺🇸 Josephine Bracamontes
 * TKO||1 (4)
 * 2000-12-03
 * align=left|🇺🇸 Miccosukee Indian Gaming Resort, Miami, Florida
 * align=left|
 * - align=center
 * Win
 * 1–0
 * align=left|🇺🇸 Chris Sepulvado
 * TKO||2 (4)
 * 2000-10-21
 * align=left|🇺🇸 Silver Star Casino, Philadelphia, Mississippi
 * align=left|Professional debut.

title: Jessica Rakoczy


text:
User talk:Nosceteipsum

Hello, and welcome to Wikipedia! We welcome and appreciate your contributions, such as Universitatea de Medicina si Farmacie Carol Davila din Bucuresti, but we regretfully cannot accept copyrighted text or images borrowed from either web sites or printed material. This article appears to be a direct copy from http://www.univermed-cdgm.ro/?pid=319. As a copyright violation, Universitatea de Medicina si Farmacie Carol Davila din Bucuresti appears to qualify for speedy deletion under the speedy deletion criteria. Universitatea de Medicina si Farmacie Carol Davila din Bucuresti has been tagged for deletion, and may have been deleted by the time you see this message. If the source is a credible one, please consider rewriting the content and citing the source. If you believe that the article is not a copyright violation, or if you have permission from the copyright holder to release the content freely under the GFDL, you can comment to that effect on Talk:Universitatea de Medicina si Farmacie Carol Davila din Bucuresti. If the article has already been deleted, but you have a proper release, you can reenter the content at Universitatea de Medicina si Farmacie Carol Davila din Bucuresti, after describing the release on the talk page. However, you may want to consider rewriting the content in your own words. Thank you, and please feel free to continue contributing to Wikipedia. -- RHaworth 07:20, 9 October 2005 (UTC)

File source problem with File:Umf bucuresti1.jpg
Thank you for uploading File:Umf bucuresti1.jpg. I noticed that the file's description page currently doesn't specify who created the content, so the copyright status is unclear. If you did not create this file yourself, you will need to specify the owner of the copyright. If you obtained it from a website, please add a link to the page from which it was taken, together with a brief restatement of the website's terms of use of its content. If the original copyright holder is a party unaffiliated with the website, that author should also be credited. Please add this information by editing the image description page.

If the necessary information is not added within the next days, the image will be deleted. If the file is already gone, you can still make a request for undeletion and ask for a chance to fix the problem.

Please refer to the image use policy to learn what images you can or cannot upload on Wikipedia. Please also check any other files you have uploaded to make sure they are correctly tagged. Here is a [ list of your uploads]. If you have any questions or are in need of assistance please ask them at the Media copyright questions page. Thank you. ~ Rob 13 Talk 17:57, 2 October 2017 (UTC)

title: User talk:Nosceteipsum


text:
Template talk:Nihongo

Minor bug with preview rendering
I've noticed a small glitch in how MediaWiki Page Previews and this template interact. Two instances of the bug can be seen in the hover preview for this link: Kyoto Animation. If the template call is followed by a comma, there is an extra space rendered in between.

Any ideas on how to fix it? — Goszei (talk) 00:00, 3 December 2020 (UTC)
 * I'm not convinced that the 'problem' is the fault of this template. Compare the actual text in the first line of Kyoto Animation with the first line of text in the popup:
 * Kyoto Animation Co., Ltd. (Japanese: 株式会社京都アニメーション, Hepburn: Kabushiki-gaisha Kyōto Animēshon), often abbreviated KyoAni (京アニ, Kyōani), is ...
 * Kyoto Animation Co., Ltd., often abbreviated KyoAni , is ...
 * The parenthetical text has been dropped. Each parenthetical is preceded with a space character and followed with a comma.  I suspect that the popup doesn't know what to do with the template so it preserves whatever was around it.
 * —Trappist the monk (talk) 00:35, 3 December 2020 (UTC)
 * Hm... the "lang-xx" templates and "zh" template render this properly, though; see the popups for French Navy and Shang dynasty. I think the parser is confused by how (unlike those templates) Nihongo also generates the parentheses, instead of just the information inside them.
 * Maybe this could be fixed by somehow getting the "space" generated inside the template to be ignored by the parser. — Goszei (talk) 01:42, 3 December 2020 (UTC)
 * Compare the raw markup:
 * Kyoto Animation:
 * French Navy:
 * Shang dynasty:
 * The parenthetical is created by in Kyoto Animation whereas the parentheses are manually placed in French Navy and Shang dynasty.  But, here is an example that exhibits the problem but doesn't use a template:
 * USS Benjamin Franklin. The raw markup is:
 * The popup removed the parenthetical hull designator but kept the space and the comma. This is more-or-less the same, doesn't have a trailing comma and doesn't exhibit the problem:
 * USS Will Rogers (SSBN-659)
 * Still not convinced that the problem is with ; if it were, then Benjamin Franklin wouldn't exhibit the problem...
 * —Trappist the monk (talk) 02:19, 3 December 2020 (UTC)
 * The popup removed the parenthetical hull designator but kept the space and the comma. This is more-or-less the same, doesn't have a trailing comma and doesn't exhibit the problem:
 * USS Will Rogers (SSBN-659)
 * Still not convinced that the problem is with ; if it were, then Benjamin Franklin wouldn't exhibit the problem...
 * —Trappist the monk (talk) 02:19, 3 December 2020 (UTC)
 * Still not convinced that the problem is with ; if it were, then Benjamin Franklin wouldn't exhibit the problem...
 * —Trappist the monk (talk) 02:19, 3 December 2020 (UTC)

"Don't use the 'lead' parameter in biographical articles"?
This seems like a given to me, per this, but is it a given to everyone else? If not, what do folks think of my reasoning? Should we rūru-ka this if we haven't already? Hijiri 88 ( 聖やや ) 20:00, 31 December 2020 (UTC)

Template-protected edit request on 20 March 2021
To add an additional output format order for the template's arguments, I'd like to request merging the code I propose on the page Module:Nihongo krt.

To do such a thing, I have created a template page: Template:Nihongo krt to output in the format: KANJI/KANA (ROMAJI, ENGLISH, EXTRA) EXTRA

Since the syntax is the same as the existing templates for Nihongo and Nihongo3, this provides an additional option for editors to present Japanese text in a consistent way in articles.

Why do we need another format?

Currently the format focuses on "English" first (T:Nihongo) or "Rōmaji" first (T:Nihongo3). However in linguistics pages that analyse the pronunciation and conjugations of Japanese words, we need the kanji/kana to be the main focus within this context (since you cannot differentiate linguistic patterns with rōmaji, as rōmaji doesn't discriminate kanji). So for the context of pronunciation and conjugations, we need an easy template that puts the kanji first with a quick rōmaji pronunciation guide beside it. In many cases for these articles, the semantic meaning of the words isn't relevant either, so we don't need to crowd the text with an English translation for each one.

The code is already working, however it would be more synergous if it were merged into one module rather than having almost identical concurrent modules doing the same thing. JKVeganAbroad (talk) 17:55, 20 March 2021 (UTC)
 * Why do we need another format? I have no opinion; others may.
 * The documentation at suggests that that template is inconsistent with, , and .  That choice seems misguided to me.  Editors regularly get the parameter order wrong with these templates so it is, I think, important that all of the nihongo family maintain a consistent parameter order.  Since I'm talking about consistency, the template name should probably be  (what does the 't' stand for?)
 * No testcases? How do we know that the template works as it should?
 * —Trappist the monk (talk) 18:55, 20 March 2021 (UTC)
 * No testcases? How do we know that the template works as it should?
 * —Trappist the monk (talk) 18:55, 20 March 2021 (UTC)

 * Hi Trappist the monk, thank you for reading over this proposal and the code! To address your points:
 * 1. At first I was going to make this its own independent module, but after consideration, I changed my mind during the coding (I came to the same conclusions that you mentioned about editors mixing up parameter ordering). Indeed, the template was re-coded to (yes indeed) be compatible with, , and , with the parameters in the same positions.
 * I thought I had corrected the documentation to reflect this, but I missed a few sections (it was late at night for me, sorry). I've amended the documentation as such (sorry about the trouble).
 * 2. Since I'm talking about consistency, the template name should probably be (instead of  )
 * As for this, I'm not familiar with the existing naming conventions, so I trust and endorse your suggestion. I've already made such changes, and re-pointed the URLs in this discussion towards this new name.
 * 3. what does the 't' stand for? "t" is for "translation". Perhaps it could be "e" for English, but I wanted the template to be multi-lingual friendly for other Wikipedia languages. I'm not sure about the validity of my judgement here.
 * 4. I've created a testcases page, thank you for the advice.
 * Thank you again for your constructive criticism so far. Do you have any more insights we could build upon?
 * JKVeganAbroad (talk) 06:51, 21 March 2021 (UTC)
 * Except for the glaringly obvious, the test cases look like they are correct.
 * —Trappist the monk (talk) 11:42, 26 March 2021 (UTC)
 * That's great news. Module:Nihongo krt is a fork from the current version of Module:Nihongo, so assuming nobody objects to this addition, should I go ahead and modify the Module:Nihongo/sandbox to ensure the other testcases (Nihongo testcases, Nihongo3 testcases, Nihongo foot testcases) produce identical results?
 * JKVeganAbroad (talk) 13:41, 26 March 2021 (UTC)
 * You could; that is, after all, what sandboxes are for.
 * I gather that the glaringly obvious to me isn't glaringly obvious to you.
 * —Trappist the monk (talk) 14:06, 26 March 2021 (UTC)
 * Indeed, if theres an obvious problem I haven't noticed it. What's the issue?
 * I'll try to modify the main sandbox later tonight.
 * JKVeganAbroad (talk) 05:17, 27 March 2021 (UTC)
 * FOLLOW-UP: Is the obvious thing that the error message is recycled from Nihingo3?
 * If so, that's because I need help to implement a proper error message, as it seems from the code that error-message handling isn't self-contained within the Module:Nihongo code, and is outsourced to some other script on Wikipedia... I don't know where that is.
 * JKVeganAbroad (talk) 05:31, 27 March 2021 (UTC)
 * —Trappist the monk (talk) 14:06, 26 March 2021 (UTC)
 * Indeed, if theres an obvious problem I haven't noticed it. What's the issue?
 * I'll try to modify the main sandbox later tonight.
 * JKVeganAbroad (talk) 05:17, 27 March 2021 (UTC)
 * FOLLOW-UP: Is the obvious thing that the error message is recycled from Nihingo3?
 * If so, that's because I need help to implement a proper error message, as it seems from the code that error-message handling isn't self-contained within the Module:Nihongo code, and is outsourced to some other script on Wikipedia... I don't know where that is.
 * JKVeganAbroad (talk) 05:31, 27 March 2021 (UTC)

I fixed the error message; I misread the code at first, but after re-reading it, the error message code wasn't complicated at all. It assumes the same error for all templates, and the only variant is the template title. Anyway, I've replaced the code in the Module:Nihongo/sandbox and all sandbox testcases (Nihongo testcases, Nihongo3 testcases, Nihongo foot testcases, Nihongo krt testcases) are identical to the live testcases. It seems the code is ready for merging. JKVeganAbroad (talk) 12:00, 27 March 2021 (UTC)

Template-protected edit request on 20 March 2021
To add an additional output format order for the template's arguments, I'd like to request merging the code I propose on the page Module:Nihongo krt.

I have created a template page: to output in the format: KANJI/KANA (ROMAJI, TRANSLATION (English), EXTRA) EXTRA

This is like, except followed by additional information in parenthesis.

(Somebody closed this edit request because "there is not yet a specific request here with consensus", so I assume I have to create this new request now that I've addressed the concerns).

JKVeganAbroad (talk) 01:49, 22 March 2021 (UTC)

 * Support. It's a good thing that the parameter orders in this new template match the other Nihongo templates. It would be nice if all of the templates could be simplified down to just one that uses an order parameter, but that's a project for another day. — Goszei (talk) 01:45, 23 March 2021 (UTC)
 * done
 * —Trappist the monk (talk) 13:01, 27 March 2021 (UTC)
 * Thank you so much! --JKVeganAbroad (talk) 14:05, 27 March 2021 (UTC)
 * Thank you so much! --JKVeganAbroad (talk) 14:05, 27 March 2021 (UTC)

Template-protected edit request on 30 May 2021 — Kerning issues
The Nihongo module automatically applies italics formatting to rōmaji text. However, in 3 select cases where the rōmaji touches the closing parenthesis bracket, kerning issues emerge. This means the italics letters are rendered such that the final character overlaps with the closing parenthesis character, which can lead to accessibility and reading issues.

Wikipedia recommends using a  character in these situations to correct kerning issues and improve readability. Many editors may not even notice the problem or know how to correct it manually. Furthermore, doing this manually is costly for the page-size on pages that use hundreds of nihongo modules (for example, if this merge proposal were accepted, the Japanese verb conjugation would be reduced by 1400 bytes by eliminating the 200  codes currently in place).

I've proposed an amendment to the Nihongo module code to automatically include a  in the 3 cases where kerning problems are likely to emerge. You can notice the difference in test cases 69 and 70 of nihongo and test case 46 of nihongo krt (nihongo3 and nihongo foot are unaffected by kerning problems).

Since adding the  is invisible, amongst only 3 syntax cases and improves the visibility and accessibility of the formatted output, I doubt this would create objections in the community.

Kind regards, JKVeganAbroad (talk) 15:12, 30 May 2021 (UTC)
 * On my machine with my browser (chrome current version)  renders roughly the same width as a generic space character so the offset between the trailing italicized character and the closing parenthesis is objectionably wide (especially when italicized character is not bolded); cf:
 * l) ←  – no space
 * l ) ←  – generic space
 * l ) ←  –
 * and when bolded:
 * l) ←  – no space
 * l ) ←  – generic space
 * l ) ←  –
 * perhaps a better solution is css:
 * l ) ←  – css
 * l ) ←  – css
 * —Trappist the monk (talk) 15:43, 30 May 2021 (UTC)
 * I've been using Firefox, but I couldn't replicate the problem on Chrome or other browsers on my machine. I'm running macOS, so it might be a rendering issue with the code on Chrome for Windows or Linux, or some other sort of interference.
 * But regardless, I really like your solution for two reasons:
 * 1) Presumably it resolves the issue on your machine, and therefore other people's machines too, and
 * 2) It doesn't add an extra annoying space character if people try to copy and paste the romaji, thus it doesn't introduce character interference.
 * I implemented your suggestion in the sandbox, and the test-cases render perfectly across my browsers and devices (thank you!). Does it render okay on your end?
 * — JKVeganAbroad (talk) 00:53, 31 May 2021 (UTC)
 * ✅ — Martin (MSGJ · talk) 11:11, 7 June 2021 (UTC)
 * You're a legend, thank you! — JKVeganAbroad (talk) 12:12, 7 June 2021 (UTC)

Template-protected edit request on 7 June 2021 — Kerning issues
This is awkward. Basically for the same reasons as the edit request above, I propose this amendment to the Nihongo module code to automatically use CSS via including  to avoid 6 fringe cases where the italics formatting of rōmaji text causes kerning issues. Specifically, these are visible in test cases 69 and 73 of nihongo and test cases 44, 46, 47 and 48 of nihongo krt (nihongo3 and nihongo foot are unaffected by kerning problems). Notice how the letter "j" touches the first opening parenthesis bracket. The letters "y" and "p" are also affected in this way. The goal is to improve the visibility and accessibility of the formatted output. Kind regards, JKVeganAbroad (talk) 13:13, 7 June 2021 (UTC)
 * I wondered this at the time of the other edit request but didn't voice it. Would it not be better to apply this kerning only when it is needed rather than always regardless of need?  So only kern those initial lowercase letters that have a descender [jpy] that touches the parenthesis and those final uppercase or lowercase letters with an ascender that touche the parenthesis [dfklt] [EFHIJKMNTUVWXYZ].
 * lowercase with descenders:
 * (g – doesn't need kerning
 * (j
 * (p
 * (q – doesn't need kerning
 * (y
 * lowercase with ascenders:
 * b) – doesn't need kerning
 * d)
 * f)
 * h) – doesn't need kerning
 * i)
 * j)
 * k)
 * l)
 * t)
 * lowercase without ascenders or descenders:
 * a) – doesn't need kerning
 * c) – doesn't need kerning
 * e) – doesn't need kerning
 * m) – doesn't need kerning
 * n) – doesn't need kerning
 * o) – doesn't need kerning
 * r)
 * s) – doesn't need kerning
 * u) – doesn't need kerning
 * v)
 * w)
 * x)
 * z)
 * uppercase:
 * A) – doesn't need kerning
 * B) – doesn't need kerning
 * C) – doesn't need kerning – needs kerning on my system (JKVeganAbroad)
 * D) – doesn't need kerning
 * E)
 * F)
 * G) – doesn't need kerning
 * H)
 * I)
 * J)
 * K)
 * L) – doesn't need kerning
 * M)
 * N)
 * O) – doesn't need kerning
 * P) – doesn't need kerning – needs kerning on my system (JKVeganAbroad)
 * Q) – doesn't need kerning
 * R) – doesn't need kerning – needs kerning on my system (JKVeganAbroad)
 * S) – doesn't need kerning – needs kerning on my system (JKVeganAbroad)
 * T)
 * U)
 * V)
 * W)
 * X)
 * Y)
 * Z)
 * punctuation:
 * ])
 * )) – doesn't need kerning
 * —Trappist the monk (talk) 13:56, 7 June 2021 (UTC)
 * …Would it not be better to apply this kerning only when it is needed rather than always regardless of need?…
 * Hey yeah, you're right of course. First and foremost, it's kind of a bother to learn a new programming language, so this was the most efficient "solution" I could come up with (i.e. the lazy "Well, if it works…" solution). Secondly, to be honest, I'm not exactly keen to research how to do it. Even if I could implement some sort of substitution via simple RegEx, I don't really understand or know how to work with variables in the Lua language (I mean, all the variables are  (wtf?!) Why aren't they unique? Hahaha omg plz halp ). So basically my own shortcomings are the reason I proposed this workaround. EDIT: I don't think it's terrible though, I doubt anyone would notice (also since even with this solution I think the added gap is just the tiniest bit too small for comfort, but at least there's technically no overlap).
 * Would you be able to help me?
 * By the way, I added some "test cases" to the list you provided, and added some disagreements where my system (macOS, Firefox, latest) presents kerning overlapping.
 * Cheers — JKVeganAbroad (talk) 14:33, 7 June 2021 (UTC)
 * Hold on just a second.
 * I've just doubled the gap from  to , and it looks marvelous. So much better for the opening and closing parenthesis brackets.
 * BUT doubling the gap, which properly solves the problem, creates the exact problem you implicitly anticipated: The gap is noticeably too large in the cases where characters don't need it: see the test cases 3, 7, 25, 29, 49 and 53 of nihongo and test cases 5, 6, 7, 15, 16, 17, 25, 26, 27, 36, 37 and 38 of nihongo krt.
 * The solution you proposed—only when required—is the solution we need. Could you please lend your expertise, if you can?
 * — JKVeganAbroad (talk) 15:09, 7 June 2021 (UTC)
 * To do that I'm going to remove the current kerning from the sandbox. I will also set this edit request to answered to prevent an inadvertent update to the live module.  If we don't find a reasonable solution, we can restore the sandbox.
 * —Trappist the monk (talk) 15:31, 7 June 2021 (UTC)
 * Yes, good idea. — JKVeganAbroad (talk) 15:41, 7 June 2021 (UTC)
 * The solution you proposed—only when required—is the solution we need. Could you please lend your expertise, if you can?
 * — JKVeganAbroad (talk) 15:09, 7 June 2021 (UTC)
 * To do that I'm going to remove the current kerning from the sandbox. I will also set this edit request to answered to prevent an inadvertent update to the live module.  If we don't find a reasonable solution, we can restore the sandbox.
 * —Trappist the monk (talk) 15:31, 7 June 2021 (UTC)
 * Yes, good idea. — JKVeganAbroad (talk) 15:41, 7 June 2021 (UTC)

@Trappist the monk, the function you've added to the sandbox works really well in the test cases (nihongo, nihongo krt). The moment I read this code was the moment I knew you are Neo and can read the Matrix! I can't thank you enough for your coding. I vote yes to merging your proposal. — JKVeganAbroad (talk) 02:37, 8 June 2021 (UTC)
 * done.
 * —Trappist the monk (talk) 12:43, 8 June 2021 (UTC)
 * Thank you, my hero! — JKVeganAbroad (talk) 12:50, 8 June 2021 (UTC)

Feedback: I think the space is way too much for the cases that don't need kerning, as marked by Trappist above, (this is a bug, see below) and still a little too much for the cases that do need kerning. On my browser at least, it looked like an errant space, which I tried to remove. — Goszei (talk) 01:46, 10 June 2021 (UTC)

 * Oh, I see the problem. At Hololive Production there is spacing applied at the end of "Kabushiki-gaisha" because it is wikilinked, which isn't picked up as a case to avoid spacing like if it were unlinked. This is also a problem with other markup: at Japanese verb conjugation it is applied to "kaban o motte iru" only when "iru" is bolded and the markup is between the letters and the parenthesis. I am not sure if the initial minor kerning problem is worth fixing if the solution needs to be become increasingly Frankenstein-y. — Goszei (talk) 01:52, 10 June 2021 (UTC)
 * I think that the gap should be at maximum .15em, which is what is applied by templates in the Template:'" family. — Goszei (talk) 01:57, 10 June 2021 (UTC)
 * Thanks for the feedback, and thanks even more so for identifying it as a bug caused by assuming wiki markup is a text-character.
 * As for your opinion about the maximum being .15em, I'll test it out in the sandbox.
 * An unforseen consequence of catering to punctuation characters. A compromise is to remove punctuation characters from automatic kerning overlap prevention, but ideally the code could be enhanced to differentiate wiki markup from punctuation text. I might be able to address the bug.
 * Wish me luck! — JKVeganAbroad (talk) 13:23, 10 June 2021 (UTC)
 * —Trappist the monk (talk) 13:36, 10 June 2021 (UTC)
 * @Trappist the monk fixed the code already, what a champion! I updated the sandbox to use the .15em that you suggested, and it looks fine to me; I have no objections. I support the proposed updated code. — JKVeganAbroad (talk) 14:59, 10 June 2021 (UTC)
 * Nice fix. On my browser (Chrome), I find that .05em is sufficient to totally eliminate the bad kerning. Results may vary, but .05 looks the most natural to me, while .1em and .15em definitely raise an eyebrow as "noticeable", and stand out too much when reading. I would agitate for a value of .05, or the lowest that we can go above that. — Goszei (talk) 16:51, 10 June 2021 (UTC)
 * Honestly .1em wasn't enough for my system, so I'm a little concerned you want it thinner. Is there a way to see what you're seeing? i.e. screenshots? For reference, I'm running macOS, tested on Firefox, Chrome, Edge, Safari (the OS and the software are all the current versions). Furthermore, Safari in particular seemed to have an uncomfortably thinner gap than the other browsers (i.e. too thin at 0.15em). — JKVeganAbroad (talk) 17:25, 10 June 2021 (UTC)
 * Here is a screenshot: (running Chrome on Windows 10). I suppose it is a matter of personal taste somewhat as well, but I think 0em looks weird, .05em looks the most natural, that 0.1 is pushing it, and that .15 is too much, and approaches my brain reading that as "an errant space". "Totally eliminate" was an exaggeration, judging by the "f" in particular, but overall I think it is most acceptable. I did this screenshot in my sandbox (Special:Permalink/1027919750), and inspected the page and manually changed the values. Here is a version that can be used to compare: Special:Permalink/1027922382. — Goszei (talk)  19:32, 10 June 2021 (UTC)
 * I also solicited from screenshots from users in the WP:DISCORD, and this is what they look like :   . — Goszei (talk)  20:06, 10 June 2021 (UTC)
 * —Trappist the monk (talk) 13:36, 10 June 2021 (UTC)
 * @Trappist the monk fixed the code already, what a champion! I updated the sandbox to use the .15em that you suggested, and it looks fine to me; I have no objections. I support the proposed updated code. — JKVeganAbroad (talk) 14:59, 10 June 2021 (UTC)
 * Nice fix. On my browser (Chrome), I find that .05em is sufficient to totally eliminate the bad kerning. Results may vary, but .05 looks the most natural to me, while .1em and .15em definitely raise an eyebrow as "noticeable", and stand out too much when reading. I would agitate for a value of .05, or the lowest that we can go above that. — Goszei (talk) 16:51, 10 June 2021 (UTC)
 * Honestly .1em wasn't enough for my system, so I'm a little concerned you want it thinner. Is there a way to see what you're seeing? i.e. screenshots? For reference, I'm running macOS, tested on Firefox, Chrome, Edge, Safari (the OS and the software are all the current versions). Furthermore, Safari in particular seemed to have an uncomfortably thinner gap than the other browsers (i.e. too thin at 0.15em). — JKVeganAbroad (talk) 17:25, 10 June 2021 (UTC)
 * Here is a screenshot: (running Chrome on Windows 10). I suppose it is a matter of personal taste somewhat as well, but I think 0em looks weird, .05em looks the most natural, that 0.1 is pushing it, and that .15 is too much, and approaches my brain reading that as "an errant space". "Totally eliminate" was an exaggeration, judging by the "f" in particular, but overall I think it is most acceptable. I did this screenshot in my sandbox (Special:Permalink/1027919750), and inspected the page and manually changed the values. Here is a version that can be used to compare: Special:Permalink/1027922382. — Goszei (talk)  19:32, 10 June 2021 (UTC)
 * I also solicited from screenshots from users in the WP:DISCORD, and this is what they look like :   . — Goszei (talk)  20:06, 10 June 2021 (UTC)
 * @Trappist the monk fixed the code already, what a champion! I updated the sandbox to use the .15em that you suggested, and it looks fine to me; I have no objections. I support the proposed updated code. — JKVeganAbroad (talk) 14:59, 10 June 2021 (UTC)
 * Nice fix. On my browser (Chrome), I find that .05em is sufficient to totally eliminate the bad kerning. Results may vary, but .05 looks the most natural to me, while .1em and .15em definitely raise an eyebrow as "noticeable", and stand out too much when reading. I would agitate for a value of .05, or the lowest that we can go above that. — Goszei (talk) 16:51, 10 June 2021 (UTC)
 * Honestly .1em wasn't enough for my system, so I'm a little concerned you want it thinner. Is there a way to see what you're seeing? i.e. screenshots? For reference, I'm running macOS, tested on Firefox, Chrome, Edge, Safari (the OS and the software are all the current versions). Furthermore, Safari in particular seemed to have an uncomfortably thinner gap than the other browsers (i.e. too thin at 0.15em). — JKVeganAbroad (talk) 17:25, 10 June 2021 (UTC)
 * Here is a screenshot: (running Chrome on Windows 10). I suppose it is a matter of personal taste somewhat as well, but I think 0em looks weird, .05em looks the most natural, that 0.1 is pushing it, and that .15 is too much, and approaches my brain reading that as "an errant space". "Totally eliminate" was an exaggeration, judging by the "f" in particular, but overall I think it is most acceptable. I did this screenshot in my sandbox (Special:Permalink/1027919750), and inspected the page and manually changed the values. Here is a version that can be used to compare: Special:Permalink/1027922382. — Goszei (talk)  19:32, 10 June 2021 (UTC)
 * I also solicited from screenshots from users in the WP:DISCORD, and this is what they look like :   . — Goszei (talk)  20:06, 10 June 2021 (UTC)

Thanks for those crowdsourced screenshots, I understand what the problem is now. The fonts are different, comparing the Microsoft environment to the Apple environment (and presumably Linux). The gaps are significantly larger in those screenshots compared to my devices. Hmm, what should we do? Is there way for CSS to target iOS and macOS environments to have a larger margin-gap? — JKVeganAbroad (talk) 15:01, 11 June 2021 (UTC)

I disagree with the notion of "If it's a problem with the client's system then we won't attempt to fix it". If a reasonable workaround can be ascertained, then there's really no reason to intentionally not discover it. Also, we're talking about Apple systems here, that's no insignificant type of system (and the most universally consistent one at that). Thirdly, I'd argue that the inconvenience of a perceived erroneous space is a lesser problem than unreadable overlapping characters (accessibility is more important). Fourthly, CSS is highly standardised and not particularly unpredictable across different systems these days; rather than inconsistent CSS margin widths, the true issue is uncontrollable fonts with irregular widths.
 * Comment: Sorry to sound negative, but this whole enterprise (I mean "kerning issue", not "Wikipedia") seems to be ill-conceived. If on some system, with some font, some spacing is non-ideal, this is a problem for the font. It is completely inappropriate to go around trying to improve this in just one tiny corner of Wikipedia. Can someone show some test cases, with image captures, so we can see whether this is genuinely a general issue for all systems. (I understand that in a very specific situation, where you are producing fixed (i.e. print) output, it may be appropriate to make specific adjustments. Personally I have been known to jiggle the spacing with css when making a poster with the word ピアノ, because katakana was "really" meant to be vertical, where it looks fine, but when written horizontally the gap between ア and ノ opens up a kind of "river", and moving ア a smidgen to the right gives better balance. But I would not dream of suggesting going through WP making this sort of global edit...) Imaginatorium (talk) 18:14, 11 June 2021 (UTC)
 * I agree with Imaginatorium. I question the wisdom of a CSS solution for the issue of kerning, as it evidently has highly unpredictable results across different systems and fonts. Perhaps a solution could be implemented elsewhere (some Googling indicates there is a CSS property for this? perhaps could be implemented higher-up, or just applied locally by a user), but I don't think doing so in a template is an appropriate way of handling this. — Goszei (talk) 20:18, 11 June 2021 (UTC)
 * As for test cases with screenshots, there are the sandbox test cases at the bottom of the pages (nihongo testcases, nihongo krt testcases). Feel free to add more test cases. If you have access to any Apple device you'll see the problem, but as for screenshots, where do you want them?
 * Also, I'll ask again, is there a way to use CSS to target Apple systems?
 * — JKVeganAbroad (talk) 12:09, 12 June 2021 (UTC)

 * Hmm. It is not just a question of not wanting to kludge round some problem, it's also a question of how/where to do it. Basically if all Apple fonts(??) have a bug that makes some italic letters crash into a non-italic closing parenthesis, then to work around this needs some very high level kludge in the WP style sheets, so this is mended everywhere, not just in the nihongo template. (An odd place for it to be a problem, because I would expect italics within non-italic parentheses to be Hepburn, and no normal Japanese word in Hepburn ends with a letter with an ascender, does it?)
 * You can sense (kludgily) whether you have an Apple device in css, as in this Stackoverflow question. But this would have to be in the stylesheet, not embedded in inline css, which I think is all that a template can generate.
 * My knowledge of typography is very much at the dilettante level; aren't parentheses around italics meant to be italic too? Input from a typography expert might help. About the testcases: what we need is a sample of the problem shown with the prekludge template, with image captures from different systems. If someone starts this, I will be happy to upload a picture of what I see (Linux something). Imaginatorium (talk) 14:19, 12 June 2021 (UTC)
 * You're right, there's no appropriate means to address a specific system. "kludge" is not the way.
 * After doing some reading and light testing, there might be a better CSS workaround that minimizes the impact. We can change the CSS style of the first or final letter (in the specific cases where kerning is desired):
 * renders: ( pi )
 * If the (pi) above looks good across all browsers/systems, then this workaround is better than the margin-gap workaround. — JKVeganAbroad (talk) 15:45, 12 June 2021 (UTC)
 * Um, not so good methinks. For the sake of exaggeration:
 * → ( pi )
 * If this is indeed a global (to Wikipedia) problem, then it seems to me that the global solution is to:
 * confirm that readers and editors think that it is a problem
 * determine whether brackets that wrap italic text should be upright or should also be italicized; best done at one of the MOS: talk pages?
 * if brackets are not to be italicized, determine if it is possible to reliably detect user agent details an apply some sort of appropriate css; may require MediaWiki developer action
 * That list may be incomplete.
 * —Trappist the monk (talk) 16:02, 12 June 2021 (UTC)
 * Since the nihongo module uses a hybrid of non-italicised text and italicised text, I think it seems odd to make the pair of parenthesis in italics... (and let's not even consider only one of the parenthesis in italics, omg). But I guess it's stranger still that this hasn't been corrected in the entire history of Wikipedia.
 * As for the exaggeration, unless you're trying to convey that you see a big gap at .08em, I'm not sure I follow what you're trying to say? I mean, to use an analogy, a little bit of medicine is the cure, too much medicine is poison. So we should consider using as little medicine as we need, right?
 * Do we really need, for just a limited set of characters under 7 specific scenarios, to request a global solution for all of Wikipedia? To be clear, I don't oppose this idea, it's the best possible outcome after all. — JKVeganAbroad (talk) 17:08, 12 June 2021 (UTC)
 * I was trying to show that in your example,  applies to all characters in the
 * ( some pi ) ←
 * But, written another way, cf:
 * (some p i ) ←
 * (some pi ) ←
 * These look the same to me.
 * If the (italicized characters clashing with upright parentheses) is  restricted to limited set of characters under 7 specific scenarios but occurs more broadly such that the community (once made aware of the problem) believe that readability is impaired, then the wider community should decide if the problem is sufficiently significant to warrant a significantly sufficient solution (yeah, I like alliteration).  A significantly sufficient solution would likely require changes to MediaWiki:Common.css and, to reliably detect user's agent, perhaps changes to the Mediawiki javascript suite.
 * —Trappist the monk (talk) 18:12, 12 June 2021 (UTC)
 * —Trappist the monk (talk) 18:12, 12 June 2021 (UTC)

Ahh, I wasn't clear enough about my example. My example was a stripped-down bare-bones "proof of concept", using only 2 problematic kerning characters as the first and final character, and not the intended for the final code. If my (pi) example looks bad at .8em, then the proposed "solution" will also fail for all other cases; however if the (pi) example looks okay, then we can proceed with more tests (comparing screen-captures) to see if it's viable. The span shouldn't capture the entire romaji word for this workaround, or the result will be the problem you exhibited. I guess you're right though, that a Mediawiki change would benefit everyone. I have no idea how to go about this. Edit: You're right, letter-spacing vs margin-left renders a pixel-perfect replica of each other, this is not the solution either. Damn. — JKVeganAbroad (talk) 03:06, 13 June 2021 (UTC) Me again. @Trappist the monk, for the time being, would you be able to consolidate the wiki-markup bug-patch to the Nihongo main code? — JKVeganAbroad (talk) 11:25, 13 June 2021 (UTC)
 * I don't know what it is that you are asking. What wiki-markup bug-patch?  Consolidate how or with what?
 * —Trappist the monk (talk) 11:35, 13 June 2021 (UTC)
 * To be more specific, this patch that you made to the sandbox fixes the bug where wiki-markup is parsed as valid characters requiring kerning. If you could consolidate this code variance with the nihongo module, it would stop the errors that Goszei noticed at the start of this discussion. — JKVeganAbroad (talk) 12:56, 13 June 2021 (UTC)
 * done
 * —Trappist the monk (talk) 13:33, 13 June 2021 (UTC)

Template-protected edit request on 18 June 2021 — Compromise: Reducing fringe cases
1029697775 I propose this compromise. As mentioned in the discussions above, perhaps we could italicise the parenthesis to solve the problem. I disagree with mix-matching unitalicised opening brackets with italicised closing brackets (or vise versa). However, in my proposal, I remove the fringe case where ENGLISH (ROMAJI) happens, by italicising the parenthesis in this case. This reduces the fringe cases to case 70 and 73 of nihongo test cases and 44, 47 and 48 of nihongo krt. That's 5 cases in total.

In addition, I did gradual testing and I'm okay to reduce the gap in these 5 fringe cases to 0.09em, as per the proposal.

What do you think?

JKVeganAbroad (talk) 02:17, 18 June 2021 (UTC)
 * Earlier in this train of discussions I wrote:

 * Have these issues been addressed? Where?
 * Out of curiosity, these searches:
 * 87,801
 * 312,111 (times out)
 * If there is any validity to these searches, then these results would suggest that editors prefer that upright parentheses bracket italicized text. If that is the case, then this edit request should not be honored.
 * —Trappist the monk (talk) 13:06, 18 June 2021 (UTC)
 * As per your regex search results, particularly given that the second one times out, I agree that this edit request should not be honored. I don't believe it's necessary to determine this at one of the Manual of Style pages, since the timed-out search results are rather conclusive—democratically—that italicizing the brackets is not preferred. So my opinion of your #2 point is that this has been determined, and brackets that wrap italic text should be upright.
 * As for point #1, this requires a poll of some sort, in a place of some sort.
 * As for #3, that can only really proceed after receiving the community opinion from point #1. If the community doesn't see a problem, then it's futile to investigate a solution.
 * So I guess I vote that point #1 should be a priority. However, in the meantime, the suggestion of removing the current kerning compensation implementation is not an idea I support. Readability > noticing erroneous spaces, in my opinion. — JKVeganAbroad (talk) 13:54, 19 June 2021 (UTC)
 * So I guess I vote that point #1 should be a priority. However, in the meantime, the suggestion of removing the current kerning compensation implementation is not an idea I support. Readability > noticing erroneous spaces, in my opinion. — JKVeganAbroad (talk) 13:54, 19 June 2021 (UTC)

Template-protected edit request on 21 June 2021 — Compromise: Reducing width of compensation gap
I propose another compromise. I realise this is an ongoing discussion and that constantly updating the module whilst the code is contentious isn't an ideal situation, but perhaps changing the appearance of the kerning compensation gap will also change the perception of the discussion.

Regrettably, I suggested a change from .1em to .2em without proper testing. The larger gap appeared more comfortable at the time, but I now believe my perception was misjudged. I've since done a major lang/transl/nihongo template implementation on the Japanese grammar page to bring it in line with accessible HTML language markup, and that page uses the nihongo template extensively. It's clear to me that a .2em gap is excessive under a variety of italics lettering. Tweaking the CSS in my browser's developer kit proved that .09em is acceptable on my system.

The nihongo test cases and nihongo krt test cases indicate that the proposed code doesn't cause detectable failures, so it's possible to merge.

If possible, I'd like to see this code merged tentatively whilst we continue the discussion about the wider implications of kerning issues amongst different systems on Wikipedia.

— JKVeganAbroad (talk) 14:19, 21 June 2021 (UTC)

Comment: Briefly, I repeat my earlier comment. I think this project is ill-conceived. If the kerning rules for some fonts on some systems are less than satisfactory, the project has to be to get the kerning rules improved. Fiddling with a tiny corner of WP to kludge round this is not a good strategy, and will inevitably end up wasting someone else's time eventually, so I oppose the whole idea, even if revised, compromised, or whatever. Imaginatorium (talk) 15:30, 21 June 2021 (UTC)
 * — I don't understand this argument. Before I took initiative to resolve this issue through the, I used   on every occurrence in the nihongo romaji syntax. This was very inefficient: laborious, and added an annoying invisible character if people copied and pasted the text. But it resolved the kerning problem. After the code change was implemented on nihongo, it was also laborious to remove the   from the articles; however at least the problem was resolved for every nihongo code thereafter.
 * If this problem gets a global solution in the future, we only need to modify the code of one page: the . That doesn't fit the definition of wasting time, in my opinion.
 * However the risk of not having a local solution is that other users might use  characters, or equivalent manual workarounds on a case-by-case basis, in the same way I did. We can't expect them to have the realisation to change the nihongo module themselves. Furthermore, it's clearly much more of a waste-of-time if a global solution is implemented and we have to seek out the manual   overrides people have used in the nihongo module to avoid kerning issues.
 * So in summary, I don't understand how this whole idea will inevitably end up wasting someone else's time eventually. Editing only the nihongo module itself is saving time, I think.
 * I can understand the other points you raised, though. — JKVeganAbroad (talk) 16:16, 21 June 2021 (UTC)
 * Belated response to your reasonable question. Of course I can't say exactly how time will be wasted, but suppose your idea is followed through... Then there will be hundreds of templates like 'Nihongo' with kludgy edits to adjust the kerning on various combinations of letters in italic. (I was wrong, btw, in claiming that romanised Japanese doesn't end with letters with ascenders, because lowercase 'i' has the dot, which is in the position of an ascender.) Anyway, I think that your original technique of putting thin-space characters in various bits of WP text is the Wrong Way to approach the problem, and putting CSS adjustments in templates is also the Wrong Way. Undeniably, this Wrong Way is likely to waste less time than the original Wrong Way, but that doesn't make it the right way. Imaginatorium (talk) 11:34, 10 July 2021 (UTC)
 * ❌ The discussion below (at ) renders this request moot. Procedurally declining. * Pppery * it has begun... 19:20, 16 July 2021 (UTC)

Consensus?
Where does consensus stand right now on the live change? I believe that it should be reversed for now, pending a wider discussion of the problem and whether a solution that is somewhat consistent can be found. Pinging previous commenters in discussion. — Goszei (talk) 01:48, 18 June 2021 (UTC)

 * I am not sure what do with this discussion, as it seems to have stalled with a weak consensus against the implemented change (weak because there has only been 4 editors involved). I made several attempts to expand the discussion at WT:JAPAN and VPT to no avail. I am not sure the procedural path is here (maybe a reversal on Trappist's part, and then the opening of a wider thread in a more central venue? an RfC? I'm really not sure). I think all parties are interested in seeing more participation and a wider discussion of the problem.
 * I have pinged the two other involved editors here to discuss the procedural path forward. — Goszei (talk) 23:21, 4 July 2021 (UTC)
 * I support the suggestion for an RfC, because basically we need more opinions. — JKVeganAbroad (talk) 01:09, 5 July 2021 (UTC)
 * I have reversed the changes in question, due to the weak consensus against them at the present time. No prejudice to a future, neutrally-worded, and thorough RfC. — Goszei (talk) 05:20, 10 July 2021 (UTC)
 * I too am against solving font rendering kerning issues here in this Scribunto module. Frankly this is a hack to resolving the issue that should be solved in the browser or the fonts themselves. If we are proposing a hackish workaround for these issues, these should be handled in a single centralized place (e.g., a kerning module) which can be updated as the technology changes to fix the problem where it exists (i.e., the hack can be adjusted as the source of the problem gets resolved over time). I further think this should use CSS and not yield any Unicode characters such as thin or hair spaces that could get picked up when copying text (since kerning is not really a part of the text itself but how it is rendered). —Uzume (talk) 06:11, 12 July 2021 (UTC)
 * I'm disappointed with this outcome. Especially when Goszei proposed an RfC and then just decided "whatever, I'll just change it myself without doing the RfC". I'm also unsatisfied with the way it was reverted, because some of the newer revisions removed terminology from the code ("an experiment to implement...") but Goszei re-introduced it. Ultimately, I'm unwilling to pursue a global correction, since I don't have the skills or knowledge required, but I hope somebody does. This kerning issue is, after all, affecting every iPhone, iPad and macOS device on the planet, and that's no small minority worthy of dis-consideration. — JKVeganAbroad (talk) 03:22, 18 July 2021 (UTC)

Fix the "Hepburn" linked page in Bengali Template.
The word "Hepburn" in nihongo template redirects to "Hepburn romanization" wiki page. But word "হেপবার্ন" (hepburn) in Bengali Template doesn't redirects to the actual bangla wiki page of Hepburn "হেপবার্ন রোমান লিপি", like the en template; rather it promotes to Create a whole page because it doesn't exists.

Now, I can create a page in this "হেপবার্ন" name and redirect it to the actual one; but fixing it in the core would better I think. Every bangla wiki pages that used this "nihongo" template the Hepburn(হেপবার্ন) word is in RED, even though it exists. And probably this occurrence is from the start of this template. Yet, isn't gotten fixed.

Anybody in charge of this template or with authority, kindly can you fix this problem? Word "হেপবার্ন" should get linked to the wiki page named "হেপবার্ন রোমান লিপি".

Thank you for reading. লাবিব আহমদ (talk) 06:07, 11 June 2021 (UTC)
 * This is about bn:টেমপ্লেট:Nihongo? That template isn't protected so you should be able to change   to   yourself.
 * —Trappist the monk (talk) 11:54, 11 June 2021 (UTC)

Usage of 'lead=yes' parameter
There doesn't seem to be any official guidance for where and when to use the lead=yes parameter, and usage is irregular and sparse. Compare Mitsubishi (uses lead=yes) and Sony (doesn't use lead=yes) for example. There is also the suggestion above in this talk page that the parameter should not be used on biographical articles, i.e. where a Japanese name is the lead.

 * 1) Is this parameter necessary in the first place? The suggestion is that the lead needs to identify to unfamiliar readers what language they are reading. Is this really necessary when most articles about Japanese companies, people etc. say that the subject is Japanese in the lead?
 * 2) If the parameter is deemed necessary, should leads which are not using it be changed to use the parameter where appropriate, for example in Sony or Yamaha?
 * 3) If the parameter is deemed necessary, should it be used on biographical articles? What about all other articles where the English name is a direct Hepburn romanization of the Japanese? (Example: Yorushika.)

— Jthistle38 (talk) 16:08, 7 January 2022 (UTC)

Does no one have an opinion on this matter? Or is this talk page completely unmonitored? — JThistle38 (talk) 19:10, 6 February 2022 (UTC)
 * This page is monitored; there are 85 editors who watch this page (whether all 85 are still active editors is an unknown). I suspect that the nature of this question has more to do with style than with the template itself.  Perhaps your question is better asked at MOS:JAPAN (278 watchers) with notice to WT:JAPAN (464 watchers) – same caveats apply.
 * yes was added to as a result of this discussion from March–October 2011.
 * —Trappist the monk (talk) 19:35, 6 February 2022 (UTC)
 * Ok, I may bring it up there then. Many thanks. — JThistle38 (talk) 21:53, 6 February 2022 (UTC)
 * Ok, I may bring it up there then. Many thanks. — JThistle38 (talk) 21:53, 6 February 2022 (UTC)

Literal translation inside parentheses?
This would be a useful option, the extra2 setting outside of the brackets only seems appropriate for the (niche?) case where it's being used in a deflist.

If this template is used at the start of an article's lead, having the literal translation outside of the brackets doesn't read well, the only options being to put the literal translation in its own, second set of brackets (as in the Sokoban article), or to not use the template. --Lord Belbury (talk) 09:22, 6 June 2022 (UTC)

 * What is wrong with using just the normal 'extra' parameter? i.e.
 * giving
 * Sokoban (倉庫番)
 * — Jthistle38 (talk) 09:39, 6 June 2022 (UTC)
 * — Jthistle38 (talk) 09:39, 6 June 2022 (UTC)

 * Oh! You're right, that's exactly what I needed, I must have missed it because the documentation examples don't include it. I'll add it there. Thank you. --Lord Belbury (talk) 09:47, 6 June 2022 (UTC)

Hepburn Romanizations don't follow normal rules?
The examples of Hepburn Romanizations seem to me to not follow the conventions used throughout the majority of English Wikipedia.

"Tokyo Tower" appears to be a proper noun, as it is written in English with both words capitalized. Why is the Hepburn Tōkyō tawā, as if the term isn't a proper noun, and not Tōkyō Tawā?

Why is Sōko-ban written with a hyphen? It's written Sōkoban in the word's English Wiktionary article, which follows the ALA-LC romanization rules for spacing romanization of Japanese. Tempjrds (talk) 23:53, 18 September 2022 (UTC)
 * If there is a fault with Tōkyō tawā and Sōko-ban, it is not the fault of the template but, rather, a fault in the choices made by editors using the template.
 * I don't know anything about Hepburn or ALA-LC romanizations (and I don't want to know), but I gotta wonder why you are using ALA-LC rules as evidence of someone's failure to follow Hepburn rules. That just doesn't make sense to me.
 * —Trappist the monk (talk) 00:25, 19 September 2022 (UTC)
 * Trappist: These are the example words used in the template docs. if you feel the docs can be improved in this regard, please go ahead and do so! It's worth noting that this template makes no demands about how words are romanized - it simply provides a way to easily lay out Japanese text with a corresponding English translation and romanization. It doesn't care what romanization method is used. Caring about that is the job of WikiProject Japan, I think. — Jumbo T (talk) 17:54, 20 September 2022 (UTC)
 * Trappist: These are the example words used in the template docs. if you feel the docs can be improved in this regard, please go ahead and do so! It's worth noting that this template makes no demands about how words are romanized - it simply provides a way to easily lay out Japanese text with a corresponding English translation and romanization. It doesn't care what romanization method is used. Caring about that is the job of WikiProject Japan, I think. — Jumbo T (talk) 17:54, 20 September 2022 (UTC)

forking
Module:Nihongo was forked to support a new template. Forking is generally considered a bad thing so I have modified and updated Module:Nihongo so that it can support and other templates for non-Japanese text. Module:Nihongo should probably be renamed to reflect its ability to be language neutral though I haven't been able to think of a good name – if you know a good name for the generalized module, let me know. Adding set of -like templates for another language simply requires the addition of a set of configuration tables (located at the top of the module code).

Famous last words, this update should not have broken any existing, , , or templates. If it did, please let me know.

—Trappist the monk (talk) 13:15, 8 October 2022 (UTC)

Abbreviation
Hi. What's the recommended usage syntax for including an abbreviation, please? For example, JEITA would preferably appear as follows:
 * Japan Electronics and Information Technology Industries Association (JEITA; Japanese: 社団法人電子情報技術産業協会, Hepburn: Shadan-hōjin Denshi Jōhō Gijutsu Sangyō Kyōkai)

Instead, it produces:
 * Japan Electronics and Information Technology Industries Association (Japanese: 社団法人電子情報技術産業協会, Hepburn: Shadan-hōjin Denshi Jōhō Gijutsu Sangyō Kyōkai, JEITA)

Thanks. fgnievinski (talk) 02:46, 2 June 2023 (UTC)

Excluding English label
I want to use this template without inserting English label. Every time I made that label empty, the template will include the English version of the Japanese automatically. I just need Kanji/Kana along with the romanization. Any help for this problem? ZanzibarSailor (talk) 23:49, 14 September 2023 (UTC)
 * I don't know what you mean by English label. You can simply omit the English translation if that is what you're looking for:
 * → Tōkyō tawā (東京タワー)
 * or you can use and  to make a custom rendering:
 * → (東京タワー)
 * —Trappist the monk (talk) 00:25, 15 September 2023 (UTC)

Any support for square brackets?
Any support for square brackets to use within parentheses? —  AjaxSmack 14:09, 11 March 2024 (UTC)
 * What support do you think is required? Inputs to the template may include square brackets.  Always give a real-life example of what you think does not work.
 * —Trappist the monk (talk) 14:26, 11 March 2024 (UTC)
 * Just the standard (if not universal) use of square brackets for nested parentheticals. It's come up in edits I've made in the past, but I don't remember where.  I usually just avoid this template when I'm writing and recast the sentence when I'm editing.  Here's a hypothetical case though: "The bowed legs of the table (despite the Japanese name sabi-wabi (寂び侘び)) are neither subdued nor austere."  While in this case I would replace the parentheses (brackets) with commas, in other cases it won't work, like in "The 45 cm (1.5-shaku (尺)) flute is an integral part of the orchestra." —  AjaxSmack  00:03, 12 March 2024 (UTC)
 * First off, if you going to use this template, use it correctly.  Above you wrote:
 * → sabi-wabi (寂び侘び)
 * → shaku (尺)
 * You should have written:
 * → sabi-wabi (寂び侘び)
 * → shaku (尺)
 * Yeah, the renderings the same but in fact they aren't; cf:
 * sabi-wabi (寂び侘び)
 * sabi-wabi (寂び侘び)
 * Pretty sure that we could add a parameter, yes (default case ) or some such, that would cause Module:Nihongo to render square brackets instead of parentheses.
 * —Trappist the monk (talk) 00:55, 12 March 2024 (UTC)
 * Thanks for the usage tip. Such arcanity is why I usually avoid this template. —  AjaxSmack  03:32, 12 March 2024 (UTC)

title: Template talk:Nihongo


text:
Shin-Aomori Station

Shin-Aomori Station (新青森駅) is a railway station in the city of Aomori, Aomori Prefecture, Japan, operated by the East Japan Railway Company (JR East) and the Hokkaido Railway Company (JR Hokkaido).

Lines
Shin-Aomori Station is the northern terminus of the Ōu Main Line from Fukushima via Akita (a distance of 486.3 km), although most trains continue to Aomori. It also forms the northern terminus of the high-speed Tōhoku Shinkansen line from Tokyo (a distance of 674.0 km), operated by JR East, and the starting point of the Hokkaido Shinkansen to Shin-Hakodate-Hokuto (a distance of 148.9 km), operated by JR Hokkaido.

Station layout
The conventional Ōu Main Line has a single island platform, serving two tracks. In addition to regular Ōu Main Line trains, the station serves two round-trips per day of Aoimori Railway trains, as well as two round-trips of the irregular Resort Asunaro (direct to Noheji and the Ōminato Line). Upon the opening of the Tōhoku Shinkansen extension on 4 December 2010, the station became the southern terminus of Hakuchō Limited express services to Hakodate via the Tsugaru Kaikyō Line, which ceased upon commencement of the Hokkaidō Shinkansen in March 2016.

The Shinkansen portion of the station, which opened on 4 December 2010, consists of two elevated island platforms serving four tracks. The platforms are 263 meters long and capable of handling 10-car trains. The station has a Midori no Madoguchi staffed ticket office.

Previously, Shin-Aomori Station was an unmanned station consisting of a single side platform for bi-directional traffic.

History
Shin-Aomori Station opened on 1 November 1986 as a station on the Japanese National Railways (JNR). With the privatization of JNR on 1 April 1987, it came under the operational control of JR East. Work on a new station building began in July 2007, and was completed in 2010 ahead of the opening of the Tōhoku Shinkansen extension on 4 December 2010.

The Hokkaido Shinkansen to Shin-Hakodate-Hokuto opened on 26 March 2016, and is being extended to Sapporo, due to open in 2031. Shinkansen services replaced the former Hakucho and Super Hakucho limited express services from March 2016.

Passenger statistics
In fiscal 2016, the conventional portion station was used by an average of 3,619 passengers daily (boarding passengers only) and the Shinkansen portion by 4,033 passengers. The passenger figures for previous years are as shown below.

Surrounding area

 * Aomori-Nishi High School
 * Shinjo Elementary School
 * Galatown Aomori West Mall
 * Aomori Kenko Land
 * Aomori Kenko Land

title: Shin-Aomori Station